authorizing user: An UMA-defined variant of an [OAuth20] resource owner; a web user who configures an authorization manager with policies that control how it makes access decisions when a requester attempts to access a protected resource at a host.

authorization manager (AM): An UMA-defined variant of an [OAuth20] authorization server that carries out an authorizing user's policies governing access to a protected resource.

protected resource: An access-restricted resource at a host.

host: An UMA-defined variant of an [OAuth20] resource server that enforces access to the protected resources it hosts, as decided by an authorization manager.

token validation URL: The URL at an authorization manager that a host can use to validate an access token.

claim: A statement (in the sense of [IDCclaim]). Claims are conveyed by a requester on behalf of a requesting party to an authorization manager in an attempt to satisfy an authorizing user's policy.

requester: An UMA-defined variant of [OAuth20] client that seeks access to a protected resource.

requesting party: A web user, or a corporation (or other legal person), that uses a requester to seek access to a protected resource.


Requirements for the resource owner

Requirements for the protected resource


The protocol is divided into three parts:

  1. The introduction of the Host and Authorization Manager
  2. The retrieval of an Access Token for a Host by a Requester
  3. The access to the Protected Resource on the Host by the Requester

The first step is only needed once per Host and Authorization Manager. In this step the resource owner decides which AM is handling access to the protected resource on that Host. The resource owner can either choose
The Resource Owner which has a protected resource on Host decides that the access to this resource is being managed by the AM he chooses.

Step 1: Introduction of Host and AM

In this step the following needs to be achieved:

The protocol involves some steps:

  1. User provisions host with AM location (out of band)
  2. Host obtains AM metadata via hostmeta
  3. Host initiates an OAuth 2.0 Web Server flow to obtain an access token from the AM

The User provisions the Host with an AM location

How this is done is out of scope. Examples can be that the URL is entered or that the Host looks up the User's webfinger profile and finds the default AM in there. The AM is only given as domain name.

The Host obtains the AM metadata via a hostmeta lookup

The AM provides the following information in it's XRD:

(example XRD here)

The Host initiates an OAuth 2.0 Web Server flow to obtain an access token for the AM

The normal OAuth flow is started here with the Host Authorization Endpoint found in the metadata above. The result is the Host having an Access Token from the AM.

During this flow the user will be redirected to the AM and needs to configure the policies for this host.



Step 2: Requester obtains Access Token from AM for Host

Step 3: Requester accesses Protected Resource on Host