Abstract
This document is a non-normative set of auxiliary material produced by the User-Managed Access Work Group. It provides advice to, and discussions relevant to, developers and deployers of UMA-enabled software systems, services, and applications.
...
Regarding the resource registration API, it is common practice when using NoSQL databases to replicate entity tag (ETag HTTP header) revision information in the body of the response message as well, in a _rev
property. The API does not mandate this property (though an early pre-V1.0 draft did include this property).
...
Anchor | ||||
---|---|---|---|---|
|
When the client requests an RPT from the token endpoint, the authorization server is able to issue the token as requested, deny the request definitively, and so on. You can think of the responses as mapping to well-understood access control actions (for example, in XACML) as follows. (These are non-normative descriptions; see Grant Sec 3.3.5 and 3.3.6 for normative wording.)
Response (e.g., error code) | HTTP status code | Conditions | Meaning | Permission ticket issued? |
---|---|---|---|---|
Issue an RPT | 200 OK | Requesting side has met policy conditions | Permit | No |
invalid_grant | 400 Bad Request | Permission ticket in request not found at authorization server, or was expired, or other RFC 6749 conditions | (syntactic error) | No |
invalid_scope | 400 Bad Request | At least one requested scope didn't match any scope on any permissions on permission ticket in request, or at least one requested scope didn't match any scope the client was pre-registered for. | (syntactic error) | No |
need_info | 403 Forbidden | The authorization server needs additional information in order for a request to succeed. | Indeterminate | |
request_denied | 403 Forbidden | The client is not authorized. | Deny | |
request_submitted | 403 Forbidden | The authorization server requires intervention by the resource owner to determine whether the client is authorized. | NotApplicable |
If the authorization server does not issue a permission ticket with an error, the client must start anew in a fresh authorization process.
...
Anchor | ||||
---|---|---|---|---|
|
...
Following are specific comments on optional properties defined in the specifications.
Property (V1.0.1 references) | Recommendations |
---|---|
Core Sec 1.4: Authorization server configuration data | |
claim_token_profiles_supported | Provided as a hint; no significant impact if ignored by any party. Should be logged if ignored to help with troubleshooting. |
uma_profiles_supported | Provided as a hint; no significant impact if ignored by any party. Should be logged if ignored to help with troubleshooting. |
dynamic_client_endpoint | Authorization Server: implementations should take care to provide this parameter if support for the dynamic client registration feature is provided. Failing to provide it (or providing it erroneously) can induce incorrect handling by clients or resource servers. Clients, Resource Servers: if the parameter is not provided, clients and resources servers must assume that dynamic client registration is not possible, and should therefore not attempt such registration. |
requesting_party_claims_endpoint | Authorization Server: to avoid confusion, should provide this parameter if end-user RP claims gathering capability exists. |
Core Sec 3.4.2: RPT "Bearer" profile | |
exp | Authorization Server: since not providing this property implicitly means that the permission does not expire, the AS should take care only to ignore the parameter if a non-expiring permission is desired. It may be sensible to consider always providing a value, even if far in the future, to avoid inadvertently granting permanent permissions. |
iat | Authorization Server: Not providing the issued-at time introduces the potential for confusion at the RS about whether the token is valid or not. Resource Server: RS should consider whether the issued-at time is reasonable (allowing for potential clock skew). Ignoring the parameter, if provided, could introduce a risk of incorrectly processing a 'bad' token. |
nbf | Authorization Server: failure to provide this parameter might result in access to a resource being granted earlier than intended. The AS should consider providing a value to avoid any potential confusion. Resource Server: if the parameter is provided, it must be adhered to. If a value is not provided, the RS should assume 'now' as the nbf, and log accordingly for audit purposes. |
Core Sec 3.5.4.2: Error Details About Claims | |
name | Authorization Server: not providing a value might cause processing confusion later. The AS should consider providing this. Client: the client should consider using this value when returning any eventual results to the AS, in order to avoid confusion. |
friendly_name | Authorization Server: no significant impact; although not providing a value means that the client will have to make assumptions about how to present the claim requirement to the user. Client: no significant impact; although the client should consider using this value to help provide improved communication to the user. |
claim_type | Authorization Server: no significant impact. Client: no significant impact. |
claim_token_format | Authorization Server: failing to provide this parameter might result in a token format being return that the AS cannot then process. AS should consider providing this parameter to avoid confusion at the Client. Client: if provided, client should take account of the acceptable token formats when it returns a token to the AS. Ignoring this parameter might result in a token being returned in a format which the AS cannot process. |
issuer | Authorization Server: no significant impact. Client: ignoring this parameter, if provided, might result in a token being returned from an issuing authority which is not acceptable to the AS (and so lead to a poor user experience). |
Core Sec 3.6.3: Client Redirects Requesting Party to Authorization Server for Claims-Gathering | |
claims_redirect_uri | Authorization Server: it is recommended to include this parameter to avoid confusion or unexpected results at the AS. Client: ignoring this parameter is not recommended. |
state | As noted in the spec, it is highly recommended that this parameter be included in order to avoid cross-site request forgery. |
ticket (response) | There are no circumstances in which this parameter can reasonably be ignored. |
state (response) | There are no circumstances in which this parameter can reasonably be ignored. |
Core Sec 4.2: UMA error responses | |
error_description | No significant impact. |
error_uri | No significant impact. |
RSR Sec 2.1: Scope descriptions | |
icon_uri | Resource Server: no significant impact Authorization Server: should log that it is ignoring for troubleshooting purposes. |
RSR Sec 2.2: Resource set descriptions | |
uri | Resource Server: in many deployments, the network location for the resource set being registered will be provided by (or inferable from) the 'scope' parameter (which is required). If not, however, the resource server will most likely use the 'uri' parameter to provide the network location. Authorization Server: if the parameter is ignored, this should be logged for troubleshooting. It is unlikely to be ignored in most common scenarios. |
type | Resource Server: this can be a helpful hint to provide to the AS. Authorization Server: should log that it is ignoring for troubleshooting purposes. |
icon_uri | Resource Server: no significant impact. Authorization Server: should log that it is ignoring for troubleshooting purposes. |
RSR Sec 3: Error messages | |
error_description | Resource Server: no significant impact. Authorization Server: should log that it is ignoring for troubleshooting purposes. |
error_uri | Resource Server: no significant impact. Authorization Server: should log that it is ignoring for troubleshooting purposes. |