User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization

The authorization process involves the following activities:

• Claims collection. Claims pushing by a client is defined in Section 3.3.1, and interactive claims gathering with an end-user requesting party is defined in Section 3.3.2.
• Authorization assessment (as defined in Section 3.3.4). Authorization assessment involves the authorization server assembling and evaluating policy conditions, scopes, claims, and any other relevant information sourced outside of UMA claims collection flows, in order to mitigate access authorization risk.
• Authorization results determination (as defined in Section 3.3.4). The authorization server either returns a success code (as defined in Section 3.3.5), an RPT, and an optional PCT, or an error code (as defined in Section 3.3.6). If the error code is need_info or request_submitted, the authorization server provides a permission ticket, giving the client an opportunity to continue within the same authorization process (including engaging in further claims collection). In the case of a need_info error, the authorization server can provide hints about what the client should do next.

Different choices of claims collection methods, other inputs to authorization assessment, and need_info error hints might be best suited for different deployment ecosystems. For example, where no pre-established relationship is expected between the resource owner's authorization server and the requesting party, initial requesting party redirection might be a useful pattern, at which point the authorization server might either authenticate the requesting party locally or serve as a relying party for a remote identity provider. Where a common authorization server functions as an identity provider for all resource owners and requesting parties, having the client push claim tokens sourced from that central server itself with a pre-negotiated format and contents might be a useful pattern.

If the resource server is able to provide a permission ticket from the authorization server, it responds to the client by providing a WWW-Authenticate header with the authentication scheme UMA, with the issuer URI from the authorization server's discovery document in an as_uri parameter and the permission ticket in a ticket parameter.

For example:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: UMA realm="example",
  as_uri="https://as.example.com",
  ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de"
...

If the resource server is unable to provide a permission ticket from the authorization server, then it includes a header of the following form in its response to the client: Warning: 199 - "UMA Authorization Server Unreachable".

For example:

HTTP/1.1 403 Forbidden
Warning: 199 - "UMA Authorization Server Unreachable"
...

Without an authorization server location and permission ticket, the client is unable to continue.

The client makes a request to the token endpoint by sending the following parameters:

grant_type

REQUIRED. MUST be the value urn:ietf:params:oauth:grant-type:uma-ticket.

ticket

REQUIRED. The most recent permission ticket received by the client as part of this authorization process.

claim_token

OPTIONAL. If this parameter is used, it MUST appear together with the claim_token_format parameter. A string containing directly pushed claim information in the indicated format. It MUST be base64url encoded unless specified otherwise by the claim token format. The client MAY provide this information on both first and subsequent requests to this endpoint. The client and authorization server together might need to establish proper audience restrictions for the claim token prior to claims pushing.

claim_token_format

OPTIONAL. If this parameter is used, it MUST appear together with the claim_token parameter. A string specifying the format of the claim token in which the client is directly pushing claims to the authorization server. The string MAY be a URI. Examples of potential types of claim token formats are [OIDCCore] ID Tokens and SAML assertions.

pct

OPTIONAL. If the authorization server previously returned a PCT along with an RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that some claims represented by a PCT are likely to contain identity information about a requesting party, a client supplying a PCT in its RPT request MUST make a best effort to ensure that the requesting party using the client now is the same as the requesting party that was associated with the PCT when it was issued. The client MAY use the PCT for the same requesting party when seeking an RPT for a resource different from the one sought when the PCT was issued, or a protected resource at a different resource server entirely. See Section 5.2 for additional PCT security considerations. See Section 3.3.5 for the form of the authorization server's response with a PCT.

rpt

OPTIONAL. Supplying an existing RPT (which MAY be expired) gives the authorization server the option of upgrading that RPT instead of issuing a new one (see Section 3.3.5.1 for more about this option).

scope

OPTIONAL. A string of space-separated values representing requested scopes. For the authorization server to consider any requested scope in its assessment, the client MUST have been pre-registered for the same scope with the authorization server. The client should consult the resource server's API documentation for details about which scopes it can expect the resource server's initial returned permission ticket to represent as part of the authorization assessment (see Section 3.3.4).

Example of a request message with no optional parameters (line breaks are shown only for display convenience):

POST /token HTTP/1.1
Host: as.example.com
Authorization: Basic jwfLG53^sad$#f
...
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket
&ticket=016f84e8-f9b9-11e0-bd6f-0021cc6004de

Example of a request message that includes an existing RPT for upgrading, a scope being sought that was previously registered with the authorization server, and a PCT and a claim token for consideration in the authorization process:

POST /token HTTP/1.1
Host: as.example.com
Authorization: Basic jwfLG53^sad$#f
...
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket
&ticket=016f84e8-f9b9-11e0-bd6f-0021cc6004de
&claim_token=eyj0...
&claim_token_format=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23IDToken
&pct=c2F2ZWRjb25zZW50
&rpt=sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv
&scope=read

This specification provides a means to define profiles of claim token formats for use with UMA (see Section 4). The authorization server SHOULD document the profiles it supports in its discovery document.

The client redirects an end-user requesting party to the authorization server's claims interaction endpoint for one or more interactive claims-gathering processes as the authorization server requires. These can include direct interactions, such as account registration and authentication local to the authorization server as an identity provider, filling out a questionnaire, or asking the user to authorize persistent storage of any collected claims to optimize future authorization processes; this last example could potentially be associated with the authorization server's subsequent issuance of a PCT. Interactions could also involve further redirection, for example, for federated (such as social) authentication at a remote identity provider, and other federated claims gathering.

Redirecting the requesting party to the authorization server is one option for the client in beginning to engage with the authorization server as part of an authorization process. The client might, for example, have initiated redirection on receiving an authorization failure response containing a redirect_user hint (see Section 3.3.6). The other option is to seek issuance of an RPT at the token endpoint (see Section 3.3).

If the client intends to redirect an end-user requesting party to the claims interaction endpoint before approaching the token endpoint, this process assumes, in addition to the other assumptions in Section 3.3, that the authorization server has statically declared its claims interaction endpoint in its discovery document.

The client constructs the request URI by adding the following parameters to the query component of the claims interaction endpoint URI using the application/x-www-form-urlencoded format:

client_id

REQUIRED. The client's identifier issued by the authorization server.

ticket

REQUIRED. The most recent permission ticket received by the client as part of this authorization process.

claims_redirect_uri

REQUIRED if the client has pre-registered multiple claims redirection URIs or has pre-registered no claims redirection URI; OPTIONAL only if the client has pre-registered a single claims redirection URI. The URI to which the client wishes the authorization server to direct the requesting party's user agent after completing its interaction. The URI MUST be absolute, MAY contain an application/x-www-form-urlencoded-formatted query parameter component that MUST be retained when adding additional parameters, and MUST NOT contain a fragment component. The client SHOULD pre-register its claims_redirect_uri with the authorization server, and the authorization server SHOULD require all clients, and MUST require public clients, to pre-register their claims redirection endpoints (see Section 2). Claims redirection URIs are different from the redirection URIs defined in [RFC6749] in that they are intended for the exclusive use of requesting parties and not resource owners. Therefore, authorization servers MUST NOT redirect requesting parties to pre-registered redirection URIs defined in [RFC6749] unless such URIs are also pre-registered specifically as claims redirection URIs. If the URI is pre-registered, this URI MUST exactly match one of the pre-registered claims redirection URIs, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison).

state

RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user agent back to the client. The use of this parameter is for preventing cross-site request forgery (see Section 5.1 for further security information).

Example of a request issued by a client application (line breaks are shown only for display convenience):

GET /rqp_claims?client_id=some_client_id
&ticket=016f84e8-f9b9-11e0-bd6f-0021cc6004de
&state=abc
&claims_redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fredirect_claims HTTP/1.1
Host: as.example.com

At the conclusion of a successful interaction with the requesting party, the authorization server returns the requesting party to the client, adding the following parameters to the query component of the claims redirection URI using the application/x-www-form-urlencoded format:

ticket

REQUIRED. A permission ticket that allows the client to make further requests to the authorization server during this authorization process. The value MUST NOT be the same as the one the client used to make its request.

state

OPTIONAL. The same state value that the client provided in the request. It MUST be present if and only if the client provided it (see Section 5.1 for further security information).

Note: Interactive claims-gathering processes are outside the scope of this specification. The purpose of the interaction is for the authorization server to gather information for its own authorization assessment purposes. This redirection does not involve sending any of the information back to the client.

The authorization server MAY use interactive claims-gathering to request authorization from the requesting party for persisting claims across authorization processes. Such persisted claims will be represented by a PCT issued to the client in a subsequent step.

The client MUST ignore unrecognized response parameters. If the request fails due to a missing, invalid, or mismatching claims redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the requesting party of the error and MUST NOT automatically redirect the user agent to the invalid redirection URI.

If the request fails for reasons other than a missing or invalid claims redirection URI, the authorization server informs the client by adding an error parameter to the query component of the claims redirection URI as defined in Section 4.1.2.1 of [RFC6749].

Example of a response issued by an authorization server (line breaks are shown only for display convenience):

HTTP/1.1 302 Found
Location: https://client.example.com/redirect_claims?
ticket=cHJpdmFjeSBpcyBjb250ZXh0LCBjb250cm9s&state=abc

When the authorization server has received a request for an RPT from a client (see Section 3.3), it assesses whether the client is authorized to receive the requested RPT and determines the results.

The authorization server MUST apply the following conceptual authorization assessment calculation in determining authorization results. Note: As this calculation is internal to authorization server operations, its particulars are outside the scope of this specification.

In this assessment calculation, let a set called ClientRegistered stand for the scopes for which the client is pre-registered at the authorization server, either dynamically or through some static process. Let a set called ClientRequested stand for the scopes the client most recently requested at the token endpoint. Let a set called PermissionTicket stand for the scopes associated with the permission ticket presented by the client at the token endpoint.

1. Determine the set of requested scopes as follows: RequestedScopes = PermissionTicket ∪ (ClientRequested ∩ ClientRegistered). Treat each scope in (ClientRequested ∩ ClientRegistered) as applying to all matching resource-bound scopes in PermissionTicket.
2. Determine all operative policy conditions, and claims and other relevant information serving as input to them, for each scope assocated with RequestedScopes and evaluate its authorization status.
3. For each scope that passes the evaluation, add it to a set called CandidateGrantedScopes.

Note: Claims and other information gathered during one authorization process may become out of date in terms of their relevance for future authorization processes. The authorization server is responsible for managing such relevance wherever information associated with a PCT, or other persistently stored information, is used as input to authorization, including policy conditions themselves.

Note: Since the authorization server's policy expression and evaluation capabilities are outside the scope of this specification, any one implementation might take a simple or arbitrarily complex form, with varying abilities to combine or perform calculations over claims and their values. For example, logical operations such as accepting "either claim value A or claim value B" as correct might be possible.

In the authorization results phase, the authorization server examines the CandidateGrantedScopes set to determine whether to issue an RPT and what permissions should be associated with it.

• If CandidateGrantedScopes = RequestedScopes, then the authorization server subsequently responds with a success code and issues an RPT.
• If CandidateGrantedScopes < RequestedScopes, the authorization server subsequently issues either an RPT containing CandidateGrantedScopes, or one of the error codes, as appropriate. The reason for the two options is that granting only partial scopes might not be useful for the client's and requesting party's purposes in seeking authorization for access. The choice of error depends on the authorization server's implementation choices. The conditions for the need_info, request_denied, and request_submitted error codes are dependent on authorization assessment and thus these codes might be more likely than the others to be issued subsequent to such a calculation.

The following example illustrates authorization assessment and partial results.

• The resource server has three of the resource owner's resources of interest to the client and requesting party, photo1 and photo2 with scopes view, resize, print, and download, and album with scopes view, edit, and download. It has registered these resources and scopes at the authorization server. It considers photo1 and photo2 to be logically "inside" album.
• Though the client is unaware of the exact contents of RPTs, permissions, and permission requests, the resource server has documented its API, available scopes, and permission requesting practices. For example, if the client requests an album resource, it expects that the resource server will request a permission for the album with a scope that approximates the attempted client operation, but will also request permissions for all the photos "inside" the album, with view scope only.
• The client has a pre-registered scope with the authorization server of download. Thus, the set ClientRegistered contains download. This prepares the client to be able to request this scope dynamically on behalf of its requesting party from the token endpoint later.
• The client requests the album resource in an attempt to edit it, so the resource server makes a permission request with three permissions in it: for album with a scope of edit, and for photo1 and photo2, each with a scope of view. Thus, the set PermissionTicket contains edit and view. (Note that edit putatively applies only to the album resource and view to both the album and the photo resources, but from the client's perspective, and thus for purposes of this entire calculation sequence, scope-to-resource mapping is not performed.)
• While asking for an RPT at the token endpoint, the client requests download scope on the requesting party's behalf. Thus, the set ClientRequested contains download.
• The authorization server determines that the set RequestedScopes contains edit, view, and download.
• The resource owner has set policy conditions that allow access by this particular requesting party only to photo1 and only for view scope.
• Based on the authorization server's authorization assessment calculation, CandidateGrantedScopes contains only view, which is less than in RequestedScopes. The authorization server has a choice whether to issue an RPT (in this case, containing a permission for photo1 with view scope) or an error (say, request_denied).

See Section 5.6 for a discussion of authorization implementation threats.

If the authorization server's assessment process results in issuance of permissions, it issues the RPT with which it has associated the permissions by using the successful response form defined in Section 5.1 of [RFC6749].

The authorization server MAY return a refresh token. See Section 3.6 for more information about refreshing an RPT.

The authorization server MAY add the following parameters to its response:

pct

OPTIONAL. A correlation handle representing claims and other information collected during this authorization process, which the client is able to present later in order to optimize future authorization processes on behalf of a requesting party. The PCT MUST be unguessable by an attacker. The PCT MUST NOT disclose claims from the requesting party directly to possessors of the PCT. Instead, such claims SHOULD be associated by reference to the PCT or expressed in an encrypted format that can be decrypted only by the authorization server that issued the PCT. See Section 3.3.2 for more information about the end-user requesting party interaction option. See Section 5.2 for additional PCT security considerations.

upgraded

OPTIONAL. Boolean value. If the client submits an RPT in the request and the authorization server includes the permissions of the RPT from the request as part of the newly issued RPT, then it MUST set this value to true. If it sets the value to false or the value is absent, the client MUST act as if the newly issued RPT does not include the permissions associated with the RPT from the request. (See Section 3.3.5.1.)

The authorization server MAY include any of the parameters defined in Section 5.1 of [RFC6749] on its response, except that it SHOULD NOT include the scope parameter. This is because for an RPT's permissions, each scope is associated with a specific resource, even though this association is opaque to the client. Note: The outcome of authorization assessment may result in expiration periods for RPTs, permissions, and refresh tokens that can affect the client's later requests for refreshing the RPT.

Example:

HTTP/1.1 200 OK
Content-Type: application/json
... 

{  
   "access_token":"sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
   "token_type":"Bearer"
}

Example with a PCT in the response:

HTTP/1.1 200 OK
Content-Type: application/json
...

{  
   "access_token":"sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
   "token_type":"Bearer",
   "pct":"c2F2ZWRjb25zZW50"
}

3.3.5.1 Authorization Server Upgrades RPT

HTTP/1.1 200 OK
Content-Type: application/json
...

{  
   "access_token":"sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
   "token_type":"Bearer",
   "upgraded":true
}

If the client's request to the token endpoint is insufficient for granting an RPT, the authorization server responds with an error, as defined in Section 5.2 of [RFC6749] and as follows.

invalid_grant

If the provided permission ticket was not found at the authorization server, or the provided permission ticket has expired, or any other original reasons to use this error response are found as defined in [RFC6749], the authorization server responds with the HTTP 400 (Bad Request) status code.

invalid_scope

At least one of the scopes included in the request does not match an available scope for any of the resources associated with requested permissions for the permission ticket provided by the client. The authorization server MAY also return this error when at least one of the scopes included in the request does not match a scope for which the client is pre-registered with the authorization server. The authorization server responds with the HTTP 400 (Bad Request) status code.

need_info

The authorization server needs additional information in order for a request to succeed, for example, a provided claim token was invalid or expired, or had an incorrect format, or additional claims are needed to complete the authorization assessment. The authorization server responds with the HTTP 403 (Forbidden) status code. It MUST include a ticket parameter, and it MUST also include either the required_claims parameter or the redirect_user parameter, or both, as hints about the information it needs.

ticket

REQUIRED. A permission ticket that allows the client to make a further request to the authorization server's token endpoint as part of this same authorization process, potentially immediately. The value MUST NOT be the same as the one the client used to make its request.

required_claims

An array of objects that describe the required claims, with the following subparameters:

claim_token_format

OPTIONAL. An array of strings specifying a set of acceptable formats for a claim token pushed by the client containing this claim, as defined in Section 3.3.1. Any one of the referenced formats would satisfy the authorization server's requirements. Each string MAY be a URI.

claim_type

OPTIONAL. A string, indicating the expected interpretation of the provided claim value. The string MAY be a URI.

friendly_name

OPTIONAL. A string that provides a human-readable form of the claim's name. This can be useful as a "display name" for use in user interfaces in cases where the actual name is complex or opaque, such as an OID or a UUID.

issuer

OPTIONAL. An array of strings specifying a set of acceptable issuing authorities for the claim. Any one of the referenced authorities would satisfy the authorization server's requirements. Each string MAY be a URI.

name

OPTIONAL. A string (which MAY be a URI) representing the name of the claim; the "key" in a key-value pair.

redirect_user

The claims interaction endpoint URI to which to redirect the end-user requesting party at the authorization server to continue the process of interactive claims gathering, as defined in Section 3.3.2. For example, the authorization server could require the requesting party to log in to an account, or fill out a CAPTCHA to help prove humanness, or perform any number of other interactive tasks. If the requesting party is not an end-user, then no client action is possible on receiving the hint. If a static claims interaction endpoint was also provided in the authorization server's discovery document, then this value overrides the static value. Providing a value in this response might be appropriate, for example, if the URI needs to be customized per requesting party with a query parameter.

request_denied

The client is not authorized to have these permissions. The authorization server responds with the HTTP 403 (Forbidden) status code.

request_submitted

The authorization server requires intervention by the resource owner to determine whether the client is authorized to have these permissions. The authorization server responds with the HTTP 403 (Forbidden) status code. It MUST include a ticket parameter.

ticket

REQUIRED. A permission ticket that allows the client to make one or more later polling requests to the token endpoint as part of this same authorization process, when the resource owner might have completed some approval (or denial) action. The value MUST NOT be the same as the one the client used to make its request.

interval

OPTIONAL. The minimum amount of time in seconds that the client SHOULD wait between polling requests to the token endpoint. See Section 5.5 for security considerations in scenarios involving polling, and longer-lived permission tickets.

Example when the permission ticket was not found or has expired:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
...

{  
   "error":"invalid_grant"
}

Example when the client was not authorized to have the permissions:

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store
...

{  
   "error":"request_denied"
}

Example of a need_info response with hints about required claims:

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store
...

{  
   "error":"need_info",
   "ticket":"ZXJyb3JfZGV0YWlscw==",
   "required_claims":[  
      {  
         "claim_token_format":[  
            "http://openid.net/specs/openid-connect-core-1_0.html#IDToken"
         ],
         "claim_type":"urn:oid:0.9.2342.19200300.100.1.3",
         "friendly_name":"email",
         "issuer":[  
            "https://example.com/idp"
         ],
         "name":"email23423453ou453"
      }
   ]
}

Example of a need_info response with a hint to redirect the requesting party to a claims interaction endpoint:

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store
...

{  
   "error":"need_info",
   "ticket":"ZXJyb3JfZGV0YWlscw==",
   "redirect_user":"https://as.example.com/rqp_claims?id=2346576421"
}

• URI suffix: uma2-configuration
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 2 in this document

• Metadata name: claims_interaction_endpoint
• Metadata description: endpoint metadata
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 2 in this document

• Metadata name: uma_profiles_supported
• Metadata description: profile/extension feature metadata
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 2 in this document

• Metadata name: claims_redirect_uris
• Metadata description: claims redirection endpoints
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 2 in this document

• Parameter name: claim_token
• Parameter usage location: client request, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document

• Parameter name: pct
• Parameter usage location: client request, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document

• Parameter name: pct
• Parameter usage location: authorization server response, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.5 in this document

• Parameter name: rpt
• Parameter usage location: client request, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document

• Parameter name: ticket
• Parameter usage location: client request, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document

• Parameter name: upgraded
• Parameter usage location: authorization server response, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.5 in this document

• Error name: need_info (and its subsidiary parameters)
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.6 in this document
• Error usage location: authorization server response, token endpoint

• Error name: request_denied
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.6 in this document
• Error usage location: authorization server response, token endpoint

• Error name: request_submitted (and its subsidiary ticket parameter)
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.6 in this document
• Error usage location: authorization server response, token endpoint

• Hint value: pct
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.7 in this document