Process Authorization Request
This API parses request parameters of an authorization request and returns necessary data for the authorization server implementation to process the authorization request further.
Path parameters
A service ID.
Request body
OAuth 2.0 authorization request parameters which are the request parameters that the OAuth 2.0 authorization endpoint of the authorization server implementation received from the client application.
The value of parameters is either (1) the entire query string when the HTTP method of the request from the client application is GET or (2) the entire entity body (which is formatted in application/x-www-form-urlencoded) when the HTTP method of the request from the client application is POST.
The arbitrary text to be attached to the ticket that will be issued from the /auth/authorization API.
The text can be retrieved later by the /auth/authorization/ticket/info API and can be updated by the /auth/authorization/ticket/update API.
The text will be compressed and encrypted when it is saved in the Authlete database.
Response
Authorization request processed successfully
The code which represents the result of the API call.
A short message which explains the result of the API call.
The next action that the authorization server implementation should take.
The display mode which the client application requests by display request parameter. When the authorization request does not have display request parameter, PAGE is set as the default value.
It is ensured that the value of display is one of the supported display modes which are specified by supportedDisplays configuration parameter of the service. If the display mode specified by the authorization request is not supported, an error is raised.
Values for this property correspond to the values listed in "OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, display".
The maximum authentication age. This value comes from max_age request parameter, or defaultMaxAge configuration parameter of the client application when the authorization request does not contain max_age request parameter.
See "OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, max_age" for max_age request parameter, and see "OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata, default_max_age" for defaultMaxAge configuration parameter.
The locales that the client application presented as candidates to be used for UI. This value comes from ui_locales request parameter. The format of ui_locales is a space-separated list of language tag values defined in RFC5646. See "OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, ui_locales" for details.
It is ensured that locales listed by this parameters are contained in the list of supported UI locales which are specified by supportedUiLocales configuration parameter of the service. Unsupported UI locales in the authorization request do not cause an error and are just ignored.
End-user's preferred languages and scripts for claims. This value comes from claims_locales request parameter. The format of claims_locales is a space-separated list of language tag values defined in RFC5646. See "OpenID Connect Core 1.0, 5.2. Claims Languages and Scripts" for details.
It is ensured that locales listed by this parameters are contained in the list of supported claim locales which are specified by supportedClaimsLocales configuration parameter of the service. Unsupported claim locales in the authorization request do not cause an error and are just ignored.
The list of claims that the client application requests to be embedded in the ID token. The value comes from (1) id_token in claims request parameter [1] and/or (2) special scopes (profile, email, address and phone) which are expanded to claims.
See OpenID Connect Core 1.0, 5.5. Requesting Claims using the "claims" Request Parameter for claims request parameter, and see OpenID Connect Core 1.0, 5.4. Requesting Claims using Scope Values for the special scopes.
This boolean value indicates whether the authentication of the end-user must be one of the ACRs (Authentication Context Class References) listed in acrs parameter. This parameter becomes true only when (1) the authorization request contains claims request parameter and (2) acr claim is in it, and (3) essential property of the acr claim is true. See OpenID Connect Core 1.0, 5.5.1.1. Requesting the "acr" Claim for details.
true if the value of the client_id request parameter included in the authorization request is the client ID alias. false if the value is the original numeric client ID.
The list of ACRs (Authentication Context Class References) one of which the client application requests to be satisfied for the authentication of the end-user. This value comes from acr_values request parameter or defaultAcrs configuration parameter of the client application.
See "OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, acr_values" for acr_values request parameter, and see "OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata, default_acr_values" for defaultAcrs configuration parameter.
The subject (= unique user ID managed by the authorization server implementation) that the client application expects to grant authorization. The value comes from sub claim in claims request parameter.
A hint about the login identifier of the end-user. The value comes from login_hint request parameter.
The list of values of prompt request parameter. See "OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, prompt" for prompt request parameter.
The prompt that the UI displayed to the end-user must satisfy as the minimum level. This value comes from prompt request parameter.
When the authorization request does not contain prompt request parameter, CONSENT is used as the default value.
See "OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, prompt" for prompt request parameter.
The payload part of the request object. The value of this proprty is null if the authorization request does not include a request object.
The value of the id_token property in the claims request parameter or in the claims property in a request object.
The value of the userinfo property in the claims request parameter or in the claims property in a request object.
The resources specified by the resource request parameters or by the resource property in the request object. If both are given, the values in the request object should be set. See "Resource Indicators for OAuth 2.0" for details.
The purpose request parameter is defined in 9. Transaction-specific Purpose of OpenID Connect for Identity Assurance 1.0 as follows:
purpose: OPTIONAL. String describing the purpose for obtaining certain user data from the OP. The purpose MUST NOT be shorter than 3 characters and MUST NOT be longer than 300 characters. If these rules are violated, the authentication request MUST fail and the OP returns an error invalid_request to the RP.
The content that the authorization server implementation is to return to the client application. Its format varies depending on the value of action parameter.
A ticket issued by Authlete to the service implementation. This is needed when the service implementation calls either /auth/authorization/fail API or /auth/authorization/issue API.
The grant management action of the device authorization request.
The grant_management_action request parameter is defined in Grant Management for OAuth 2.0.
the value of the grant_id request parameter of the device authorization request.
The grant_id request parameter is defined in Grant Management for OAuth 2.0 , which is supported by Authlete 2.3 and newer versions.
The subject identifying the user who has given the grant identified by the grant_id request parameter of the device authorization request. Authlete 2.3 and newer versions support Grant Management for OAuth 2.0. An authorization request may contain a grant_id request parameter which is defined in the specification. If the value of the request parameter is valid, {@link #getGrantSubject()} will return the subject of the user who has given the grant to the client application. Authorization server implementations may use the value returned from {@link #getGrantSubject()} in order to determine the user to authenticate. The user your system will authenticate during the authorization process (or has already authenticated) may be different from the user of the grant. The first implementer's draft of "Grant Management for OAuth 2.0" does not mention anything about the case, so the behavior in the case is left to implementations. Authlete will not perform the grant management action when the subject passed to Authlete does not match the user of the grant.
Names of claims that are requested indirectly by "transformed claims". A client application can request "transformed claims" by adding names of transformed claims in the claims request parameter. The following is an example of the claims request parameter that requests a predefined transformed claim named 18_or_over and a transformed claim named nationality_usa to be embedded in the response from the userinfo endpoint.
{
"transformed_claims": {
"nationality_usa": {
"claim": "nationalities",
"fn": [
[ "eq", "USA" ],
"any"
]
}
},
"userinfo": {
"::18_or_over": null,
":nationality_usa": null
}
}
The example above assumes that a transformed claim named 18_or_over is predefined by the authorization server like below.
{
"18_or_over": {
"claim": "birthdate",
"fn": [
"years_ago",
[ "gte", 18 ]
]
}
}
In the example, the nationalities claim is requested indirectly by the nationality_usa transformed claim. Likewise, the birthdate claim is requested indirectly by the 18_or_over transformed claim. When the claims request parameter of an authorization request is like the example above, this requestedClaimsForTx property will hold the following value.
[ "birthdate", "nationalities" ]
It is expected that the authorization server implementation prepares values of the listed claims and passes them as the value of the claimsForTx request parameter when it calls the /api/auth/userinfo/issue API. The following is an example of the value of the claimsForTx request parameter.
{
"birthdate": "1970-01-23",
"nationalities": [ "DEU", "USA" ]
}
the value of the transformed_claims property in the claims request parameter of an authorization request or in the claims property in a request object.
Flag which indicates whether the entity ID of the client was used when the request for the access token was made.
The list of claims that the client application requests to be embedded in userinfo responses. The value comes from the "scope" and "claims" request parameters of the original authorization request.
The information about the issuable credentials that can be obtained by presenting the access token that will be issued as a result of the authorization request.
Flag which indicates whether Native SSO is requested. This property should be set to true when all the following conditions are satisfied:
Flag indicating whether a metadata document was used to resolve client metadata for this request.
When true, the client metadata was retrieved via the CIMD mechanism rather than from the Authlete database.
Example response
{
"service": {
"number": 715948317,
"serviceName": "My Test Service",
"issuer": "https://example.com",
"supportedScopes": [
"profile",
"email",
"openid"
],
"supportedResponseTypes": [
"CODE"
],
"supportedGrantTypes": [
"AUTHORIZATION_CODE",
"REFRESH_TOKEN"
]
}
}