Overview#
Uma-configuration is a
Well-known URI defined following the
RFC 6415
The Authorization Server MUST provide configuration data in a JSON document that resides in an /uma-configuration directory at its host-meta hostmeta location. The configuration data documents conformance options and endpoints supported by the Authorization Server.
The configuration data has the following properties:
version #
REQUIRED - The version of the UMA core protocol to which this
Authorization Server conforms. The value
MUST be the string "1.0".
issuer #
REQUIRED - A
URI with no query or fragment component that the
Authorization Server asserts as its issuer identifier. This value
MUST be identical to the web location of the configuration data minus the host-meta
hostmeta and /uma-configuration path components
REQUIRED OAuth 2.0 token_type supported by this
Authorization Server for
PAT issuance. The property value is an array of string values, where each string value (which MAY be a URI) is a token type. Non-URI token type strings defined by OAuth token-defining specifications are privileged. For example, the type "bearer" stands for the
OAuth 2.0 bearer token type defined in [OAuth-bearer. The authorization server is
REQUIRED to support "bearer", and to supply this value explicitly. The authorization server MAY declare its support for additional PAT profiles.
REQUIRED OAuth 2.0 token_type supported by this authorization server for
AAT issuance. The property value is an array of string values, where each string value (which MAY be a URI) is a token type. Non-URI token type strings defined by OAuth token-defining specifications are privileged. For example, the type "bearer" stands for the OAuth bearer token type defined in
OAuth-bearer. The authorization server is
REQUIRED to support "bearer", and to supply this value explicitly. The authorization server MAY declare its support for additional AAT profiles.
REQUIRED Profiles supported by this authorization server for
RPT issuance. The property value is an array of string values, where each string value is a URI identifying an RPT profile. The authorization server is REQUIRED to support the "bearer"
RPT profile defined in Section 3.3.2, and to supply its identifying URI explicitly. The authorization server MAY declare its support for additional RPT profiles.
REQUIRED OAuth grant types supported by this authorization server in issuing
PATs. The property value is an array of string values, where each string value (which MAY be a URI) is a grant type. Non-URI token type strings defined by OAuth grant type-defining specifications are privileged. For example, the type "
authorization_code" stands for the OAuth
authorization Code Grant type defined in
OAuth 2.0.
REQUIRED OAuth grant types supported by this authorization server in issuing
AATs. The property value is an array of string values, where each string value (which MAY be a URI) is a grant type. Non-URI token type strings defined by OAuth grant type-defining specifications are privileged. For example, the type "authorization_code" stands for the OAuth authorization code grant type defined in
OAuth 2.0.
OPTIONAL Claim token format profiles supported by this authorization server. The property value is an array of string values, where each string value MAY be a URI.
OPTIONAL UMA profiles supported by this authorization server. The property value is an array of string values, where each string value is a URI identifying an UMA profile. Examples of UMA profiles are the API extensibility profiles defined in Section 5.
OPTIONAL The endpoint to use for performing dynamic client registration in the case of the use of
DynClientReg, or alternatively the reserved string "openid" in the case of the use of
OIDCDynClientReg. In the latter case, it is presumed that the resource server or client will discover the dynamic client registration endpoint from the authorization server's published OpenID Provider Configuration Information. The presence of this property indicates authorization server support for dynamic client registration feature; its absence indicates a lack of support.
REQUIRED The
endpoint URI at which the resource server or client asks the authorization server for a
PAT or
AAT. A requested scope of "
uma_protection" results in a PAT. A requested scope of "
uma_authorization" results in an
AAT. Usage of this endpoint is defined by
OAuth 2.0.
REQUIRED The endpoint URI at which the resource server gathers the consent of the end-user resource owner or the client gathers the consent of the end-user requesting party for issuance of a
PAT or
AAT respectively, if the
authorization_code" grant type is used. Usage of this endpoint is defined by
OAuth 2.0.
OPTIONAL The endpoint URI at which the authorization server interacts with the end-user requesting party to gather claims. If this property is absent, the authorization server does not interact with the end-user requesting party for claims gathering.
REQUIRED The endpoint URI at which the resource server introspects an
RPT presented to it by a client. Usage of this endpoint is defined by
OAuth 2.0 Token Introspection and Section 3.3.1. A valid
PAT MUST accompany requests to this protected endpoint.
REQUIRED The endpoint URI at which the resource server registers resource sets to put them under authorization manager protection. Usage of this endpoint is defined by
OAuth 2.0 Resource Set Registration and Section 2. A valid
PAT MUST accompany requests to this protected endpoint.
REQUIRED The endpoint URI at which the resource server registers a requested permission that would suffice for a client's access attempt. Usage of this endpoint is defined by Section 3.2. A valid PAT MUST accompany requests to this protected endpoint.
REQUIRED The endpoint URI at which the client asks for authorization data. Usage of this endpoint is defined in Section 3.4. A valid AAT and a permission ticket MUST, and an RPT MAY, accompany requests to this protected endpoint.
Example #
Example of authorization server configuration data that resides at https://example.com/.well-known/uma-configuration (note the use of https: for endpoints throughout):
{
"version":"1.0",
"issuer":"https://example.com",
"pat_profiles_supported":["bearer"],
"aat_profiles_supported":["bearer"],
"rpt_profiles_supported": ["https://docs.kantarainitiative.org/uma/profiles/uma-token-bearer-1.0"],
"pat_grant_types_supported":["authorization_code"],
"aat_grant_types_supported":["authorization_code"],
"claim_token_profiles_supported":["https://example.com/claims/formats/token1"],
"dynamic_client_endpoint":"https://as.example.com/dyn_client_reg_uri",
"token_endpoint":"https://as.example.com/token_uri",
"authorization_endpoint":"https://as.example.com/authz_uri",
"requesting_party_claims_endpoint":"https://as.example.com/rqp_claims_uri",
"resource_set_registration_endpoint":"https://as.example.com/rs/rsrc_uri",
"introspection_endpoint":"https://as.example.com/rs/status_uri",
"permission_registration_endpoint":"https://as.example.com/rs/perm_uri",
"rpt_endpoint":"https://as.example.com/client/rpt_uri"
}
this specification does not already require optional features to be documented, it is RECOMMENDED that authorization server deployers document any profiled or extended features explicitly and use configuration data to indicate their usage.
There might be more information for this subject on one of the following: