Authlete Authorization Endpoint API
API endpoints for implementing OAuth 2.0 Authorization Endpoint.
OpenAPI Specification
openapi: 3.0.3
info:
title: Authlete Authorization Endpoint API
description: "Welcome to the **Authlete API documentation**. Authlete is an **API-first service** where every aspect of the \nplatform is configurable via API. This documentation will help you authenticate and integrate with Authlete to \nbuild powerful OAuth 2.0 and OpenID Connect servers.\n\nAt a high level, the Authlete API is grouped into two categories:\n\n- **Management APIs**: Enable you to manage services and clients.\n- **Runtime APIs**: Allow you to build your own Authorization Servers or Verifiable Credential (VC) issuers.\n\n## \U0001F310 API Servers\n\nAuthlete is a global service with clusters available in multiple regions across the world:\n\n- \U0001F1FA\U0001F1F8 **US**: `https://us.authlete.com`\n- \U0001F1EF\U0001F1F5 **Japan**: `https://jp.authlete.com`\n- \U0001F1EA\U0001F1FA **Europe**: `https://eu.authlete.com`\n- \U0001F1E7\U0001F1F7 **Brazil**: `https://br.authlete.com`\n\nOur customers can host their data in the region that best meets their requirements.\n\n## \U0001F511 Authentication\n\nAll API endpoints are secured using **Bearer token authentication**. You must include an access token in every request:\n\n```\nAuthorization: Bearer YOUR_ACCESS_TOKEN\n```\n\n### Getting Your Access Token\n\nAuthlete supports two types of access tokens:\n\n**Service Access Token** - Scoped to a single service (authorization server instance)\n\n1. Log in to [Authlete Console](https://console.authlete.com)\n2. Navigate to your service → **Settings** → **Access Tokens**\n3. Click **Create Token** and select permissions (e.g., `service.read`, `client.write`)\n4. Copy the generated token\n\n**Organization Token** - Scoped to your entire organization\n\n1. Log in to [Authlete Console](https://console.authlete.com)\n2. Navigate to **Organization Settings** → **Access Tokens**\n3. Click **Create Token** and select org-level permissions\n4. Copy the generated token\n\n> ⚠️ **Important Note**: Tokens inherit the permissions of the account that creates them. Service tokens can only \n> access their specific service, while organization tokens can access all services within your org.\n\n### Token Security Best Practices\n\n- **Never commit tokens to version control** - Store in environment variables or secure secret managers\n- **Rotate regularly** - Generate new tokens periodically and revoke old ones\n- **Scope appropriately** - Request only the permissions your application needs\n- **Revoke unused tokens** - Delete tokens you're no longer using from the console\n\n### Quick Test\n\nVerify your token works with a simple API call:\n\n```bash\ncurl -X GET https://us.authlete.com/api/service/get/list \\\n -H \"Authorization: Bearer YOUR_ACCESS_TOKEN\"\n```\n\n## \U0001F393 Tutorials\n\nIf you're new to Authlete or want to see sample implementations, these resources will help you get started:\n\n- [Getting Started with Authlete](https://www.authlete.com/developers/getting_started/)\n- [From Sign-Up to the First API Request](https://www.authlete.com/developers/tutorial/signup/)\n\n## \U0001F6E0 Contact Us\n\nIf you have any questions or need assistance, our team is here to help:\n\n- [Contact Page](https://www.authlete.com/contact/)\n"
version: 3.0.16
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
servers:
- description: 🇺🇸 US Cluster
url: https://us.authlete.com
- description: 🇯🇵 Japan Cluster
url: https://jp.authlete.com
- description: 🇪🇺 Europe Cluster
url: https://eu.authlete.com
- description: 🇧🇷 Brazil Cluster
url: https://br.authlete.com
security:
- bearer: []
tags:
- name: Authorization Endpoint
description: API endpoints for implementing OAuth 2.0 Authorization Endpoint.
x-tag-expanded: false
paths:
/api/{serviceId}/auth/authorization:
post:
summary: Process Authorization Request
x-badges:
- color: red
label: Core API
description: 'This API parses request parameters of an authorization request and returns necessary data for the authorization server
implementation to process the authorization request further.
'
x-mint:
metadata:
description: This API parses request parameters of an authorization request and returns necessary data for the authorization server implementation to process the authorization request further.
content: "<Accordion title=\"Full description\" defaultOpen={false}>\nThis API is supposed to be called from within the implementation of the authorization endpoint of\nthe service. The endpoint implementation must extract the request parameters from the authorization\nrequest from the client application and pass them as the value of parameters request parameter for\nAuthlete's `/auth/authorization` API.\nThe value of `parameters` is either (1) the entire query string when the HTTP method of the request\nfrom the client application is `GET` or (2) the entire entity body (which is formatted in\n`application/x-www-form-urlencoded`) when the HTTP method of the request from the client application\nis `POST`.\nThe following code snippet is an example in JAX-RS showing how to extract request parameters from\nthe authorization request.\n```java\n@GET\npublic Response get(@Context UriInfo uriInfo)\n{\n // The query parameters of the authorization request.\n String parameters = uriInfo.getRequestUri().getQuery();\n ......\n}\n@POST\n@Consumes(MediaType.APPLICATION_FORM_URLENCODED)\npublic Response post(String parameters)\n{\n // 'parameters' is the entity body of the authorization request.\n ......\n}\n```\nThe endpoint implementation does not have to parse the request parameters from the client application\nbecause Authlete's `/auth/authorization` API does it.\nThe response from `/auth/authorization` API has various parameters. Among them, it is `action`\nparameter that the authorization server implementation should check first because it denotes the\nnext action that the authorization server implementation should take. According to the value of\n`action`, the service implementation must take the steps described below.\n\n## INTERNAL_SERVER_ERROR\n\nWhen the value of `action` is `INTERNAL_SERVER_ERROR`, it means that the request from the authorization\nserver implementation was wrong or that an error occurred in Authlete.\nIn either case, from the viewpoint of the client application, it is an error on the server side.\nTherefore, the service implementation should generate a response to the client application with\nHTTP status of \"500 Internal Server Error\". Authlete recommends `application/json` as the content\ntype although OAuth 2.0 specification does not mention the format of the error response when the\nredirect URI is not usable.\n\nThe value of `responseContent` is a JSON string which describes the error, so it can be used as\nthe entity body of the response.\n\n---\n\nThe following illustrates the response which the service implementation should generate and return\nto the client application.\n\n```\nHTTP/1.1 500 Internal Server Error\nContent-Type: application/json\nCache-Control: no-store\nPragma: no-cache\n{responseContent}\n```\nThe endpoint implementation may return another different response to the client application\nsince \"500 Internal Server Error\" is not required by OAuth 2.0.\n\n## BAD_REQUEST\n\nWhen the value of `action` is `BAD_REQUEST`, it means that the request from the client application\nis invalid.\nA response with HTTP status of \"400 Bad Request\" should be returned to the client application and\nAuthlete recommends `application/json` as the content type although OAuth 2.0 specification does\nnot mention the format of the error response when the redirect URI is not usable.\n\nThe value of `responseContent` is a JSON string which describes the error, so it can be used as\nthe entity body of the response.\n\n---\n\nThe following illustrates the response which the service implementation should generate and return\nto the client application.\n\n```\nHTTP/1.1 400 Bad Request\nContent-Type: application/json\nCache-Control: no-store\nPragma: no-cache\n{responseContent}\n```\nThe endpoint implementation may return another different response to the client application since\n\"400 Bad Request\" is not required by OAuth 2.0.\n\n## LOCATION\n\nWhen the value of `action` is `LOCATION`, it means that the request from the client application\nis invalid but the redirect URI\nto which the error should be reported has been determined.\nA response with HTTP status of \"302 Found\" must be returned to the client application with `Location`\nheader which has a redirect URI with error parameter.\n\nThe value of `responseContent` is a redirect URI with `error` parameter, so it can be used as the\nvalue of `Location` header.\n\nThe following illustrates the response which the service implementation must generate and return\nto the client application.\n\n```\nHTTP/1.1 302 Found\nLocation: {responseContent}\nCache-Control: no-store\nPragma: no-cache\n```\n\n## FORM\n\nWhen the value of `action` is `FORM`, it means that the request from the client application is\ninvalid but the redirect URI to which the error should be reported has been determined, and that\nthe authorization request contains `response_mode=form_post` as is defined in [OAuth 2.0 Form Post\nResponse Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html).\nThe HTTP status of the response returned to the client application should be \"200 OK\" and the\ncontent type should be `text/html;charset=UTF-8`.\n\nThe value of `responseContent` is an HTML which can be used as the entity body of the response.\n\n---\n\nThe following illustrates the response which the service implementation must generate and return\nto the client application.\n\n```\nHTTP/1.1 200 OK\nContent-Type: text/html;charset=UTF-8\nCache-Control: no-store\nPragma: no-cache\n{responseContent}\n```\n\n## NO_INTERACTION\n\nWhen the value of `action` is `NO_INTERACTION`, it means that the request from the client application\nhas no problem and requires the service to process the request without displaying any user interface\npages for authentication or consent. This case happens when the authorization request contains\n`prompt=none`.\nThe service must follow the steps described below.\n\n**[1] END-USER AUTHENTICATION**\n\nCheck whether an end-user has already logged in. If an end-user has logged in, go to the next step ([MAX_AGE]).\nOtherwise, call Authlete's `/auth/authorization/fail` API with `reason=NOT_LOGGED_IN` and use the response from\nthe API to generate a response to the client application.\n\n**[2] MAX AGE**\n\nGet the value of `maxAge` parameter from the `/auth/authorization` API response. The value represents\nthe maximum authentication age which has come from `max_age` request parameter or `defaultMaxAge`\nconfiguration parameter of the client application. If the value is `0`, go to the next step ([SUBJECT]).\nOtherwise, follow the sub steps described below.\n\n- (i) Get the time at which the end-user was authenticated. Note that this value is not managed by Authlete,\n meaning that it is expected that the service implementation manages the value. If the service implementation\n does not manage authentication time of end-users, call Authlete's `/auth/authorization/fail` API\n with `reason=MAX_AGE_NOT_SUPPORTED` and use the API response to generate a response to the client\n application.\n- (ii) Add the value of the maximum authentication age (which is represented in seconds) to the authentication\n time. The calculated value is the expiration time.\n- (iii) Check whether the calculated value is equal to or greater than the current time. If this condition\n is satisfied, go to the next step ([SUBJECT]). Otherwise, call Authlete's `/auth/authorization/fail`\n API with `reason=EXCEEDS_MAX_AGE` and use the API response to generate a response to the client\n application.\n\n**[3] SUBJECT**\n\nGet the value of `subject` from the `/auth/authorization` API response. The value represents an\nend-user who the client application expects to grant authorization. If the value is `null`, go to\nthe next step ([ACRs]). Otherwise, follow the sub steps described below.\n\n- (i) Compare the value of the requested subject to the current end-user.\n- (ii) If they are equal, go to the next step ([ACRs]). If they are not equal, call Authlete's\n `/auth/authorization/fail` API with `reason=DIFFERENT_SUBJECT` and use the response from the API\n to generate a response to the client application.\n\n**[4] ACRs**\n\nGet the value of `acrs` from the `/auth/authorization` API response. The value represents a list\nof ACRs (Authentication Context Class References) and comes from (1) acr claim in `claims` request\nparameter, (2) `acr_values` request parameter, or (3) `default_acr_values` configuration parameter\nof the client application.\nIt is ensured that all the ACRs in acrs are supported by the authorization server implementation.\nIn other words, it is ensured that all the ACRs are listed in `acr_values_supported` configuration\nparameter of the authorization server.\nIf the value of ACRs is `null`, go to the next step ([ISSUE]). Otherwise, follow the sub steps\ndescribed below.\n\n- (i) Get the ACR performed for the authentication of the current end-user. Note that this value is\n managed not by Authlete but by the authorization server implementation. (If the authorization server\n implementation cannot handle ACRs, it should not have listed ACRs as `acr_values_supported`.)\n- (ii) Compare the ACR value obtained in the above step to each element in the ACR array (`acrs`)\n in the listed order.\n- (iii) If the ACR value was found in the array, (= the ACR performed for the authentication of the\n current end-user did not match any one of the ACRs requested by the client application), check\n whether one of the requested ACRs must be satisfied or not using `acrEssential` parameter in the\n `/auth/authorization` API response. If the value of `acrEssential` parameter is `true`, call Authlete's\n `/auth/authorization/fail` API with `reason=ACR_NOT_SATISFIED` and use the response from the API\n to generate a response to the client application. Otherwise, go to the next step ([SCOPES]).\n\n**[5] SCOPES**\n\nGet the value of `scopes` from the `/auth/authorization` API response. If the array contains a\nscope which has not been granted to the client application by the end-user in the past, call\nAuthlete's `/auth/authorization/fail` API with `reason=CONSENT_REQUIRED` and use the response from\nthe API to generate a response to the client application. Otherwise, go to the next step ([RESOURCES]).\nNote that Authlete provides APIs to manage records of granted scopes (`/api/client/granted_scopes/*`\nAPIs), which is only available in a dedicated/onpremise Authlete server (contact sales@authlete.com\nfor details).\n\n**[6] DYNAMIC SCOPES**\n\nGet the value of `dynamicScopes` from the `/auth/authorization` API response. If the array contains\na scope which has not been granted to the client application by the end-user in the past, call\nAuthlete's `/auth/authorization/fail` API with `reason=CONSENT_REQUIRED` and use the response from\nthe API to generate a response to the client application. Otherwise, go to the next step ([RESOURCES]).\nNote that Authlete provides APIs to manage records of granted scopes (`/api/client/granted_scopes/*`\nAPIs) but dynamic scopes are not remembered as granted scopes.\n\n**[7] RESOURCES**\n\nGet the value of `resources` from the `/auth/authorization` API response. The array represents\nthe values of the `resource` request parameters. If you want to reject the request, call Authlete's\n`/auth/authorization/fail` API with `reason=INVALID_TARGET` and use the response from the API to\ngenerate a response to the client application. Otherwise, go to the next step ([ISSUE]).\nSee \"Resource Indicators for OAuth 2.0\" for details.\n\n**[8] ISSUE**\n\nIf all the above steps succeeded, the last step is to issue an authorization code, an ID token\nand/or an access token. (There is a special case, though. In the case of `response_type=none`,\nnothing is issued.) It can be performed by calling Authlete's `/auth/authorization/issue` API.\nThe API requires the following parameters. Prepare these parameters and call `/auth/authorization/issue`\nAPI and use the response to generate a response to the client application.\n- `ticket` (required)\n This parameter represents a ticket which is exchanged with tokens at `/auth/authorization/issue`.\n Use the value of `ticket` contained in the `/auth/authorization` API response.\n- `subject` (required)\n This parameter represents the unique identifier of the current end-user. It is often called \"user ID\"\n and it may or may not be visible to the user. In any case, it is a number or a string assigned\n to an end-user by the authorization server implementation. Authlete does not care about the format\n of the value of subject, but it must consist of only ASCII letters and its length must not exceed 100.\n When the value of `subject` parameter in the /auth/authorization API response is not `null`,\n it is necessarily identical to the value of `subject` parameter in the `/auth/authorization/issue`\n API request.\n The value of this parameter will be embedded in an ID token as the value of `sub` claim. When\nthe value of `subject_type` configuration parameter of the client application is `PAIRWISE`,\n the value of sub claim is different from the value specified by this parameter, See [8. Subject\nIdentifier Types](https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes) of OpenID\n Connect Core 1.0 for details about subject types.\n You can use the `sub` request parameter to adjust the value of the `sub` claim in an ID token.\n See the description of the `sub` request parameter for details.\n- `authTime` (optional)\n This parameter represents the time when the end-user authentication occurred. Its value is the\n number of seconds from `1970-01-01`. The value of this parameter will be embedded in an ID token\nas the value of `auth_time` claim.\n- `acr` (optional)\n This parameter represents the ACR (Authentication Context Class Reference) which the authentication\n of the end-user satisfies. When `acrs` in the `/auth/authorization` API response is a non-empty\n array and the value of `acrEssential` is `true`, the value of this parameter must be one of the\n array elements. Otherwise, even `null` is allowed. The value of this parameter will be embedded\n in an ID token as the value of `acr` claim.\n- `claims` (optional)\n This parameter represents claims of the end-user. \"Claims\" here are pieces of information about\n the end-user such as `\"name\"`, `\"email\"` and `\"birthdate\"`. The authorization server implementation\n is required to gather claims of the end-user, format the claim values into JSON and set the JSON\n string as the value of this parameter.\n The claims which the authorization server implementation is required to gather are listed in\n `claims` parameter in the `/auth/authorization` API response.\n For example, if claims parameter lists `\"name\"`, `\"email\"` and `\"birthdate\"`, the value of this\n parameter should look like the following.\n ```json\n {\n \"name\": \"John Smith\",\n \"email\": \"john@example.com\",\n \"birthdate\": \"1974-05-06\"\n }\n ```\n `claimsLocales` parameter in the `/auth/authorization` API response lists the end-user's preferred\n languages and scripts, ordered by preference. When `claimsLocales` parameter is a non-empty array,\n its elements should be taken into account when the authorization server implementation gathers\nclaim values. Especially, note the excerpt below from [5.2. Claims Languages and Scripts](https://openid.net/specs/openid-connect-core-1_0.html#ClaimsLanguagesAndScripts)\n of OpenID Connect Core 1.0.\n> When the OP determines, either through the `claims_locales` parameter, or by other means, that\n the End-User and Client are requesting Claims in only one set of languages and scripts, it is\n RECOMMENDED that OPs return Claims without language tags when they employ this language and script.\n It is also RECOMMENDED that Clients be written in a manner that they can handle and utilize Claims\n using language tags.\n If `claims` parameter in the `/auth/authorization` API response is `null` or an empty array,\n the value of this parameter should be `null`.\nSee [5.1. Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)\n of OpenID Connect core 1.0 for claim names and their value formats. Note (1) that the authorization\nserver implementation support its special claims ([5.1.2. Additional Claims](https://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims))\nand (2) that claim names may be followed by a language tag ([5.2. Claims Languages and Scripts](https://openid.net/specs/openid-connect-core-1_0.html#ClaimsLanguagesAndScripts)).\nRead the specification of [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)\n for details.\n The claim values in this parameter will be embedded in an ID token.\n Note that `idTokenClaims` parameter is available in the `/auth/authorization` API response.\nThe parameter has the value of the `\"id_token\"` property in the `claims` request parameter or\n in the `\"claims\"` property in a request object. The value of this parameter should be considered\n when you prepare claim values.\n- `properties` (optional)\n Extra properties to associate with an access token and/or an authorization code that may be issued\n by this request. Note that `properties` parameter is accepted only when `Content-Type` of the\n request is `application/json`, so don't use `application/x-www-form-urlencoded` for details.\n- `scopes` (optional)\n Scopes to associate with an access token and/or an authorization code. If this parameter is `null`,\n the scopes specified in the original authorization request from the client application are used.\n In other cases, including the case of an empty array, the specified scopes will replace the original\n scopes contained in the original authorization request.\n Even scopes that are not included in the original authorization request can be specified. However,\n as an exception, `openid` scope is ignored on the server side if it is not included in the original\n request. It is because the existence of `openid` scope considerably changes the validation steps\n and because adding `openid` triggers generation of an ID token (although the client application\n has not requested it) and the behavior is a major violation against the specification.\nIf you add `offline_access` scope although it is not included in the original request, keep in\n mind that the specification requires explicit consent from the user for the scope ([OpenID Connect\nCore 1.0, 11. Offline Access](https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess)).\nWhen `offline_access` is included in the original request, the current implementation of Authlete's\n `/auth/authorization` API checks whether the request has come along with `prompt` request parameter\n and the value includes consent. However, note that the implementation of Authlete's `/auth/authorization/issue`\nAPI does not perform such checking if `offline_access` scope is added via this `scopes` parameter.\n- `sub` (optional)\n The value of the `sub` claim in an ID token. If the value of this request parameter is not empty,\n it is used as the value of the `sub` claim. Otherwise, the value of the `subject` request parameter\n is used as the value of the `sub` claim. The main purpose of this parameter is to hide the actual\n value of the subject from client applications.\n Note that even if this `sub` parameter is not empty, the value of the subject request parameter\n is used as the value of the subject which is associated with the access token.\n\n## INTERACTION\n\nWhen the value of `action` is `INTERACTION`, it means that the request from the client application\nhas no problem and requires the service to process the request with user interaction by an HTML form.\nThe purpose of the UI displayed to the end-user is to ask the end-user to grant authorization to\nthe client application. The items described below are some points which the service implementation\nshould take into account when it builds the UI.\n\n**[1] DISPLAY MODE**\n\nThe response from `/auth/authorization` API has `display` parameter. It is one of `PAGE` (default),\n`POPUP`, `TOUCH` and `WAP` The meanings of the values are described in [3.1.2.1. Authentication\nRequest of OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest).\nBasically, the authorization server implementation should display the UI which is suitable for the\ndisplay mode, but it is okay for the authorization server implementation to \"attempt to detect the\ncapabilities of the User Agent and present an appropriate display\".\nIt is ensured that the value of `display` is one of the supported display modes which are specified\nby `supportedDisplays` configuration parameter of the service.\n\n**[2] UI LOCALE**\n\nThe response from `/auth/authorization` API has `uiLocales` parameter. It it is not `null`, it lists\nlanguage tag values (such as `fr-CA`, `ja-JP` and `en`) ordered by preference. The service implementation\nshould display the UI in one of the language listed in the parameter when possible. It is ensured\nthat language tags listed in `uiLocales` are contained in the list of supported UI locales which\nare specified by `supportedUiLocales` configuration parameter of the service.\n\n**[3] CLIENT INFORMATION**\n\nThe authorization server implementation should show information about the client application to\nthe end-user. The information is embedded in `client` parameter in the response from `/auth/authorization`\nAPI.\n\n**[4] SCOPES**\n\nA client application requires authorization for specific permissions. In OAuth 2.0 specification,\n\"scope\" is a technical term which represents a permission. `scopes` parameter in the response\nfrom `/auth/authorization` API is a list of scopes requested by the client application. The service\nimplementation should show the end-user the scopes.\nThe authorization server implementation may choose not to show scopes to which the end-user has\ngiven consent in the past. To put it the other way around, the authorization server implementation\nmay show only the scopes to which the end-user has not given consent yet. However, if the value\nof `prompts` response parameter contains `CONSENT`, the authorization server implementation has\nto obtain explicit consent from the end-user even if the end-user has given consent to all the\nrequested scopes in the past.\nNote that Authlete provides APIs to manage records of granted scopes (`/api/client/granted_scopes/*`\nAPIs), but the APIs work only in the case the Authlete server you use is a dedicated Authlete server\n(contact sales@authlete.com for details). In other words, the APIs of the shared Authlete server\nare disabled intentionally (in order to prevent garbage data from being accumulated) and they\nreturn 403 Forbidden.\nIt is ensured that the values in `scopes` parameter are contained in the list of supported scopes\nwhich are specified by `supportedScopes` configuration parameter of the service.\n\n**[5] DYNAMIC SCOPES**\n\nThe authorization request may include dynamic scopes. The list of recognized dynamic scopes are\naccessible by getDynamicScopes() method. See the description of the [DynamicScope](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/DynamicScope.html)\nclass for details about dynamic scopes.\n\n**[6] AUTHORIZATION DETAILS**\n\nThe authorization server implementation should show the end-user \"authorization details\" if the\nrequest includes it. The value of `authorization_details` parameter in the response is the content\nof the `authorization_details` request parameter.\nSee \"OAuth 2.0 Rich Authorization Requests\" for details.\n\n**[7] PURPOSE**\n\nThe authorization server implementation must show the value of the `purpose` request parameter if\nit supports [OpenID Connect for Identity Assurance 1.0](https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html).\nSee [8. Transaction-specific Purpose](https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#rfc.section.8)\nin the specification for details.\nNote that the value of `purpose` response parameter is the value of the purpose request parameter.\n\n**[7] END-USER AUTHENTICATION**\n\nNecessarily, the end-user must be authenticated (= must login the service) before granting authorization\nto the client application. Simply put, a login form is expected to be displayed for end-user authentication.\nThe service implementation must follow the steps described below to comply with OpenID Connect.\n(Or just always show a login form if it's too much of a bother.)\n\n- (i) Get the value of `prompts` response parameter. It corresponds to the value of the `prompt`\n request parameter. Details of the request parameter are described in [3.1.2.1. Authentication\n Request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) of OpenID Connect Core 1.0.\n- (ii) If the value of `prompts` parameter is `SELECT_ACCOUNT` display a form to let the end-user\n select on of his/her accounts for login. If `subject` response parameter is not `null`, it is the\n end-user ID that the client application expects, so the value should be used to determine the value\n of the login ID. Note that a subject and a login ID are not necessarily equal. If the value of\n `subject` response parameter is `null`, the value of `loginHint` response parameter should be referred\n to as a hint to determine the value of the login ID. The value of `loginHint` response parameter\n is simply the value of the `login_hint` request parameter.\n- (iii) If the value of `prompts` response parameter contains `LOGIN`, display a form to urge the\n end-user to login even if the end-user has already logged in. If the value of `subject` response\n parameter is not `null`, it is the end-user ID that the client application expects, so the value\n should be used to determine the value of the login ID. Note that a subject and a login ID are not\n necessarily equal. If the value of `subject` response parameter is `null`, the value of `loginHint`\n response parameter should be referred to as a hint to determine the value of the login ID. The value\n of `loginHint` response parameter is simply the value of the `login_hint` request parameter.\n- (iv) If the value of `prompts` response parameter does not contain `LOGIN`, the authorization server\n implementation does not have to authenticate the end-user if all the conditions described below\n are satisfied. If any one of the conditions is not satisfied, show a login form to authenticate\n the end-user.\n - An end-user has already logged in the service.\n - The login ID of the current end-user matches the value of `subject` response parameter.\n This check is required only when the value of `subject` response parameter is a non-null value.\n - The max age, which is the number of seconds contained in `maxAge` response parameter,\n has not passed since the current end-user logged in your service. This check is required only when\n the value of `maxAge` response parameter is a non-zero value.\n - If the authorization server implementation does not manage authentication time of end-users\n (= if the authorization server implementation cannot know when end-users logged in) and if the\n value of `maxAge` response parameter is a non-zero value, a login form should be displayed.\n - The ACR (Authentication Context Class Reference) of the authentication performed for\n the current end-user satisfies one of the ACRs listed in `acrs` response parameter. This check is\n required only when the value of `acrs` response parameter is a non-empty array.\n In every case, the end-user authentication must satisfy one of the ACRs listed in `acrs` response\n parameter when the value of `acrs` response parameter is a non-empty array and `acrEssential`\n response parameter is `true`.\n\n**[9] GRANT/DENY BUTTONS**\n\nThe end-user is supposed to choose either (1) to grant authorization to the client application or\n(2) to deny
# --- truncated at 32 KB (231 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/authlete/refs/heads/main/openapi/authlete-authorization-endpoint-api-openapi.yml