Process Authorization Request

@GET
public Response get(@Context UriInfo uriInfo)
{
    // The query parameters of the authorization request.
    String parameters = uriInfo.getRequestUri().getQuery();
    ......
}
@POST
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public Response post(String parameters)
{
    // 'parameters' is the entity body of the authorization request.
    ......
}

​

INTERNAL_SERVER_ERROR

HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{responseContent}

​

BAD_REQUEST

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{responseContent}

​

LOCATION

HTTP/1.1 302 Found
Location: {responseContent}
Cache-Control: no-store
Pragma: no-cache

​

FORM

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{responseContent}

​

NO_INTERACTION

• (i) Get the time at which the end-user was authenticated. Note that this value is not managed by Authlete, meaning that it is expected that the service implementation manages the value. If the service implementation does not manage authentication time of end-users, call Authlete’s /auth/authorization/fail API with reason=MAX_AGE_NOT_SUPPORTED and use the API response to generate a response to the client application.
• (ii) Add the value of the maximum authentication age (which is represented in seconds) to the authentication time. The calculated value is the expiration time.
• (iii) Check whether the calculated value is equal to or greater than the current time. If this condition is satisfied, go to the next step ([SUBJECT]). Otherwise, call Authlete’s /auth/authorization/fail API with reason=EXCEEDS_MAX_AGE and use the API response to generate a response to the client application.

• (i) Compare the value of the requested subject to the current end-user.
• (ii) If they are equal, go to the next step ([ACRs]). If they are not equal, call Authlete’s /auth/authorization/fail API with reason=DIFFERENT_SUBJECT and use the response from the API to generate a response to the client application.

• (i) Get the ACR performed for the authentication of the current end-user. Note that this value is managed not by Authlete but by the authorization server implementation. (If the authorization server implementation cannot handle ACRs, it should not have listed ACRs as acr_values_supported.)
• (ii) Compare the ACR value obtained in the above step to each element in the ACR array (acrs) in the listed order.
• (iii) If the ACR value was found in the array, (= the ACR performed for the authentication of the current end-user did not match any one of the ACRs requested by the client application), check whether one of the requested ACRs must be satisfied or not using acrEssential parameter in the /auth/authorization API response. If the value of acrEssential parameter is true, call Authlete’s /auth/authorization/fail API with reason=ACR_NOT_SATISFIED and use the response from the API to generate a response to the client application. Otherwise, go to the next step ([SCOPES]).

• ticket (required) This parameter represents a ticket which is exchanged with tokens at /auth/authorization/issue. Use the value of ticket contained in the /auth/authorization API response.
• subject (required) This parameter represents the unique identifier of the current end-user. It is often called “user ID” and it may or may not be visible to the user. In any case, it is a number or a string assigned to an end-user by the authorization server implementation. Authlete does not care about the format of the value of subject, but it must consist of only ASCII letters and its length must not exceed 100. When the value of subject parameter in the /auth/authorization API response is not null, it is necessarily identical to the value of subject parameter in the /auth/authorization/issue API request. The value of this parameter will be embedded in an ID token as the value of sub claim. When the value of subject_type configuration parameter of the client application is PAIRWISE, the value of sub claim is different from the value specified by this parameter, See 8. Subject Identifier Types of OpenID Connect Core 1.0 for details about subject types. You can use the sub request parameter to adjust the value of the sub claim in an ID token. See the description of the sub request parameter for details.
• authTime (optional) This parameter represents the time when the end-user authentication occurred. Its value is the number of seconds from 1970-01-01. The value of this parameter will be embedded in an ID token as the value of auth_time claim.
• acr (optional) This parameter represents the ACR (Authentication Context Class Reference) which the authentication of the end-user satisfies. When acrs in the /auth/authorization API response is a non-empty array and the value of acrEssential is true, the value of this parameter must be one of the array elements. Otherwise, even null is allowed. The value of this parameter will be embedded in an ID token as the value of acr claim.
• claims (optional) This parameter represents claims of the end-user. “Claims” here are pieces of information about the end-user such as "name", "email" and "birthdate". The authorization server implementation is required to gather claims of the end-user, format the claim values into JSON and set the JSON string as the value of this parameter. The claims which the authorization server implementation is required to gather are listed in claims parameter in the /auth/authorization API response. For example, if claims parameter lists "name", "email" and "birthdate", the value of this parameter should look like the following.
  Copy

  {
    "name": "John Smith",
    "email": "john@example.com",
    "birthdate": "1974-05-06"
  }
  
  claimsLocales parameter in the /auth/authorization API response lists the end-user’s preferred languages and scripts, ordered by preference. When claimsLocales parameter is a non-empty array, its elements should be taken into account when the authorization server implementation gathers claim values. Especially, note the excerpt below from 5.2. Claims Languages and Scripts of OpenID Connect Core 1.0.

When the OP determines, either through the claims_locales parameter, or by other means, that the End-User and Client are requesting Claims in only one set of languages and scripts, it is RECOMMENDED that OPs return Claims without language tags when they employ this language and script. It is also RECOMMENDED that Clients be written in a manner that they can handle and utilize Claims using language tags. If claims parameter in the /auth/authorization API response is null or an empty array, the value of this parameter should be null. See 5.1. Standard Claims of OpenID Connect core 1.0 for claim names and their value formats. Note (1) that the authorization server implementation support its special claims (5.1.2. Additional Claims) and (2) that claim names may be followed by a language tag (5.2. Claims Languages and Scripts). Read the specification of OpenID Connect Core 1.0 for details. The claim values in this parameter will be embedded in an ID token. Note that idTokenClaims parameter is available in the /auth/authorization API response. The parameter has the value of the "id_token" property in the claims request parameter or in the "claims" property in a request object. The value of this parameter should be considered when you prepare claim values.

• properties (optional) Extra properties to associate with an access token and/or an authorization code that may be issued by this request. Note that properties parameter is accepted only when Content-Type of the request is application/json, so don’t use application/x-www-form-urlencoded for details.
• scopes (optional) Scopes to associate with an access token and/or an authorization code. If this parameter is null, the scopes specified in the original authorization request from the client application are used. In other cases, including the case of an empty array, the specified scopes will replace the original scopes contained in the original authorization request. Even scopes that are not included in the original authorization request can be specified. However, as an exception, openid scope is ignored on the server side if it is not included in the original request. It is because the existence of openid scope considerably changes the validation steps and because adding openid triggers generation of an ID token (although the client application has not requested it) and the behavior is a major violation against the specification. If you add offline_access scope although it is not included in the original request, keep in mind that the specification requires explicit consent from the user for the scope (OpenID Connect Core 1.0, 11. Offline Access). When offline_access is included in the original request, the current implementation of Authlete’s /auth/authorization API checks whether the request has come along with prompt request parameter and the value includes consent. However, note that the implementation of Authlete’s /auth/authorization/issue API does not perform such checking if offline_access scope is added via this scopes parameter.
• sub (optional) The value of the sub claim in an ID token. If the value of this request parameter is not empty, it is used as the value of the sub claim. Otherwise, the value of the subject request parameter is used as the value of the sub claim. The main purpose of this parameter is to hide the actual value of the subject from client applications. Note that even if this sub parameter is not empty, the value of the subject request parameter is used as the value of the subject which is associated with the access token.

​

INTERACTION

• (i) Get the value of prompts response parameter. It corresponds to the value of the prompt request parameter. Details of the request parameter are described in 3.1.2.1. Authentication Request of OpenID Connect Core 1.0.
• (ii) If the value of prompts parameter is SELECT_ACCOUNT display a form to let the end-user select on of his/her accounts for login. If subject response parameter is not null, it is the end-user ID that the client application expects, so the value should be used to determine the value of the login ID. Note that a subject and a login ID are not necessarily equal. If the value of subject response parameter is null, the value of loginHint response parameter should be referred to as a hint to determine the value of the login ID. The value of loginHint response parameter is simply the value of the login_hint request parameter.
• (iii) If the value of prompts response parameter contains LOGIN, display a form to urge the end-user to login even if the end-user has already logged in. If the value of subject response parameter is not null, it is the end-user ID that the client application expects, so the value should be used to determine the value of the login ID. Note that a subject and a login ID are not necessarily equal. If the value of subject response parameter is null, the value of loginHint response parameter should be referred to as a hint to determine the value of the login ID. The value of loginHint response parameter is simply the value of the login_hint request parameter.
• (iv) If the value of prompts response parameter does not contain LOGIN, the authorization server implementation does not have to authenticate the end-user if all the conditions described below are satisfied. If any one of the conditions is not satisfied, show a login form to authenticate the end-user.
  • An end-user has already logged in the service.
  • The login ID of the current end-user matches the value of subject response parameter. This check is required only when the value of subject response parameter is a non-null value.
  • The max age, which is the number of seconds contained in maxAge response parameter, has not passed since the current end-user logged in your service. This check is required only when the value of maxAge response parameter is a non-zero value.
  • If the authorization server implementation does not manage authentication time of end-users (= if the authorization server implementation cannot know when end-users logged in) and if the value of maxAge response parameter is a non-zero value, a login form should be displayed.
  • The ACR (Authentication Context Class Reference) of the authentication performed for the current end-user satisfies one of the ACRs listed in acrs response parameter. This check is required only when the value of acrs response parameter is a non-empty array. In every case, the end-user authentication must satisfy one of the ACRs listed in acrs response parameter when the value of acrs response parameter is a non-empty array and acrEssential response parameter is true.