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.
...
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 | Yes |
request_denied | 403 Forbidden | The client is not authorized. | Deny | No |
request_submitted | 403 Forbidden | The authorization server requires intervention by the resource owner to determine whether the client is authorized. | NotApplicable | Yes |
If the authorization server does not issue a permission ticket with an error, the client must start anew in a fresh authorization process. If the authorization server does issue a permission ticket, the client has a choice whether to continue and use it, or start anew.
...
| Anchor | ||||
|---|---|---|---|---|
|
...