Authlete UserInfo Endpoint API
API endpoints for implementing OpenID Connect UserInfo Endpoint.
OpenAPI Specification
openapi: 3.0.3
info:
title: Authlete Authorization Endpoint UserInfo 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: UserInfo Endpoint
description: API endpoints for implementing OpenID Connect UserInfo Endpoint.
x-tag-expanded: false
paths:
/api/{serviceId}/auth/userinfo:
post:
summary: Process UserInfo Request
description: 'This API gathers information about a user.
'
x-mint:
metadata:
description: This API gathers information about a user.
content: '<Accordion title="Full description" defaultOpen={false}>
This API is supposed to be called from within the implementation of the [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)
of the authorization server in order to get information about the user that is associated with
an access token.
The response from `/auth/userinfo` API has various parameters. Among them, it is `action` parameter
that the authorization server implementation should check first because it denotes the next action
that the authorization server implementation should take. According to the value of `action`, the
service implementation must take the steps described below.
## INTERNAL_SERVER_ERROR
When the value of `action` is `INTERNAL_SERVER_ERROR`, it means that the request from the authorization
server implementation was wrong or that an error occurred in Authlete. In either case, from the
viewpoint of the client application, it is an error on the server side. Therefore, the service
implementation should generate a response to the client application with HTTP status of "500 Internal
Server Error".
The value of `responseContent` is a string which describes the error in the format of [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750)
(OAuth 2.0 Bearer Token Usage) so the userinfo endpoint implementation can use the value of `responseContent`
as the value of`WWW-Authenticate` header.
The following is an example response which complies with RFC 6750. Note that OpenID Connect Core
1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo
Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details.
```
HTTP/1.1 500 Internal Server Error
WWW-Authenticate: {responseContent}
Cache-Control: no-store
Pragma: no-cache
```
## BAD_REQUEST
When the value of `action` is `BAD_REQUEST`, it means that the request from the client application
does not contain an access token (= the request from the authorization server implementation to
Authlete does not contain `token` parameter).
The value of `responseContent` is a string which describes the error in the format
of [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the
userinfo endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate`
header.
The following is an example response which complies with RFC 6750. Note that OpenID Connect Core
1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo
Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details.
```
HTTP/1.1 400 Bad Request
WWW-Authenticate: {responseContent}
Cache-Control: no-store
Pragma: no-cache
```
## UNAUTHORIZED
When the value of `action` is `UNAUTHORIZED`, it means that the access token does not exist, has
expired, or is not associated with any subject (= any user account).
The value of `responseContent` is a string which describes the error in the format of [RFC
6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the userinfo
endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate`
header.
The following is an example response which complies with RFC 6750. Note that OpenID Connect Core
1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo
Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details.
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: {responseContent}
Cache-Control: no-store
Pragma: no-cache
```
## FORBIDDEN
When the value of `action` is `FORBIDDEN`, it means that the access token does not include the
`openid` scope.
The value of `responseContent` is a string which describes the error in the format of [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750)
(OAuth 2.0 Bearer Token Usage) so the userinfo endpoint implementation can use the value of `responseContent`
as the value of`WWW-Authenticate` header.
The following is an example response which complies with RFC 6750. Note that OpenID Connect Core
1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo
Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details.
```
HTTP/1.1 403 Forbidden
WWW-Authenticate: {responseContent}
Cache-Control: no-store
Pragma: no-cache
```
## OK
When the value of `action` is `OK`, it means that the access token which the client application
presented is valid. To be concrete, it means that the access token exists, has not expired, includes
the openid scope, and is associated with a subject (= a user account).
What the userinfo endpoint implementation should do next is to collect information about the subject
(user) from your database. The value of the `subject` is contained in the subject parameter in the
response from this API and the names of data, i.e., the claims names are contained in the claims
parameter in the response. For example, if the `subject` parameter is `joe123` and the claims
parameter is `[ "given_name", "email" ]`, you need to extract information about joe123''s given name
and email from your database.
Then, call Authlete''s `/auth/userinfo/issue` API with the collected information and the access token
in order to make Authlete generate an ID token.
If an error occurred during the above steps, generate an error response to the client. The response
should comply with [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750). For example, if the
subject associated with the access token does not exist in your database any longer, you may feel
like generating a response like below.
```
HTTP/1.1 400 Bad Request
WWW-Authenticate: Bearer error="invalid_token",
error_description="The subject associated with the access token does not exist."
Cache-Control: no-store
Pragma: no-cache
```
Also, an error might occur on database access. If you treat the error as an internal server error,
then the response would be like the following.
```
HTTP/1.1 500 Internal Server Error
WWW-Authenticate: Bearer error="server_error",
error_description="Failed to extract information about the subject from the database."
Cache-Control: no-store
Pragma: no-cache
```
</Accordion>
'
parameters:
- in: path
name: serviceId
description: A service ID.
required: true
schema:
type: string
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/userinfo_request'
example:
token: Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/userinfo_request'
responses:
'200':
description: User info retrieved successfully
content:
application/json:
schema:
$ref: '#/components/schemas/userinfo_response'
example:
resultCode: A091001
resultMessage: '[A091001] The access token presented at the userinfo endpoint is valid.'
action: OK
clientId: '15518267821'
clientIdAliasUsed: false
scopes:
- openid
subject: john
token: Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI
'400':
$ref: '#/components/responses/400'
'401':
$ref: '#/components/responses/401'
'403':
$ref: '#/components/responses/403'
'500':
$ref: '#/components/responses/500'
operationId: auth_userinfo_api
x-code-samples:
- lang: shell
label: curl
source: 'curl -v -X POST https://us.authlete.com/api/21653835348762/auth/userinfo \
-H ''Content-Type:application/json'' \
-H ''Authorization: Bearer V5a40R6dWvw2gMkCOBFdZcM95q4HC0Z-T0YKD9-nR6F'' \
-d ''{ "token": "Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI" }''
'
- lang: java
label: java
source: 'AuthleteConfiguration conf = ...;
AuthleteApi api = AuthleteApiFactory.create(conf);
UserInfoRequest req = new UserInfoRequest();
req.setToken("Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI");
api.userinfo(req);
'
- lang: python
source: 'conf = ...
api = AuthleteApiImpl(conf)
req = UserInfoRequest()
req.token = ''Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI''
api.userinfo(req)
'
tags:
- UserInfo Endpoint
/api/{serviceId}/auth/userinfo/issue:
post:
summary: Issue UserInfo Response
description: 'This API generates an ID token.
'
x-mint:
metadata:
description: This API generates an ID token.
content: '<Accordion title="Full description" defaultOpen={false}>
This API is supposed to be called from within the implementation of the [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)
of the authorization server in order to generate an ID token. Before calling this API, a valid
response from `/auth/userinfo` API must be obtained. Then, call this API with the access token
contained in the response and the claims values of the user (subject) associated with the access
token. See **OK** written in the description of `/auth/userinfo` API for details.
The response from `/auth/userinfo/issue` API has various parameters. Among them, it is `action`
parameter that the authorization server implementation should check first because it denotes the
next action that the authorization server implementation should take. According to the value of
`action`, the service implementation must take the steps described below.
## INTERNAL_SERVER_ERROR
When the value of `action` is `INTERNAL_SERVER_ERROR`, it means that the request from the authorization
server implementation was wrong or that an error occurred in Authlete. In either case, from the
viewpoint of the client application, it is an error on the server side. Therefore, the service
implementation should generate a response to the client application with HTTP status of "500 Internal
Server Error".
The parameter `responseContent` returns a string which describes the error in the format of [RFC
6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the userinfo
endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate`
header.
The following is an example response which complies with RFC 6750. Note that OpenID Connect Core
1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo
Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details.
```
HTTP/1.1 500 Internal Server Error
WWW-Authenticate: {responseContent}
Cache-Control: no-store
Pragma: no-cache
```
## BAD_REQUEST
When the value of `action` is `BAD_REQUEST`, it means that the request from the client application
does not contain an access token (= the request from the authorization server implementation to
Authlete does not contain `token` parameter).
The parameter `responseContent` returns a string which describes the error in the format of [RFC
6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the userinfo
endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate`
header.
The following is an example response which complies with RFC 6750. Note that OpenID Connect Core
1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo
Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details.
```
HTTP/1.1 400 Bad Request
WWW-Authenticate: {responseContent}
Cache-Control: no-store
Pragma: no-cache
```
## UNAUTHORIZED
When the value of `action` is `UNAUTHORIZED`, it means that the access token does not exist, has
expired, or is not associated with any subject (= any user account).
The parameter `responseContent` returns a string which describes the error in the format of [RFC
6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the userinfo
endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate`
header.
The following is an example response which complies with RFC 6750. Note that OpenID Connect Core
1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo
Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details.
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: {responseContent}
Cache-Control: no-store
Pragma: no-cache
```
## FORBIDDEN
When the value of `action` is `FORBIDDEN`, it means that the access token does not include the
`openid` scope.
The parameter `responseContent` returns a string which describes the error in the format of [RFC
6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the userinfo
endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate`
header.
The following is an example response which complies with RFC 6750. Note that OpenID Connect Core
1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo
Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details.
```
HTTP/1.1 403 Forbidden
WWW-Authenticate: {responseContent}
Cache-Control: no-store
Pragma: no-cache
```
## JSON
When the value of `action` is `JSON`, it means that the access token which the client application
presented is valid and an ID token was successfully generated in the format of JSON.
The userinfo endpoint implementation is expected to generate a response to the client application.
The content type of the response must be `application/json` and the response body must be an ID
token in JSON format.
The value of `responseContent` is the ID token in JSON format when `action` is `JSON`, so
a response to the client can be built like below.
```
HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/json;charset=UTF-8
{responseContent}
```
## JWT
When the value of `action` is `JWT`, it means that the access token which the client application
presented is valid and an ID token was successfully generated in the format of JWT (JSON Web Token)
([RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519)).
The userinfo endpoint implementation is expected to generate a response to the client application.
The content type of the response must be `application/jwt` and the response body must be an ID
token in JWT format.
The value of `responseContent` is the ID token in JSON format when `action` is `JWT`, so a response
to the client can be built like below.
```
HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/jwt
{responseContent}
```
</Accordion>
'
parameters:
- in: path
name: serviceId
description: A service ID.
required: true
schema:
type: string
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/userinfo_issue_request'
example:
token: Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/userinfo_issue_request'
responses:
'200':
description: User info issued successfully
content:
application/json:
schema:
$ref: '#/components/schemas/userinfo_issue_response'
example:
resultCode: A096001
resultMessage: '[A096001] An ID token was generated successfully.'
action: JSON
responseContent: '{\"exp\":1511600971,\"sub\":\"john\",\"aud\":[\"26478243745571\"],\"iss\":\"https://authlete.com\",\"iat\":1511514571}'
'400':
$ref: '#/components/responses/400'
'401':
$ref: '#/components/responses/401'
'403':
$ref: '#/components/responses/403'
'500':
$ref: '#/components/responses/500'
operationId: auth_userinfo_issue_api
x-code-samples:
- lang: shell
label: curl
source: 'curl -v -X POST https://us.authlete.com/api/21653835348762/auth/userinfo/issue \
-H ''Content-Type:application/json'' \
-H ''Authorization: Bearer V5a40R6dWvw2gMkCOBFdZcM95q4HC0Z-T0YKD9-nR6F'' \
-d ''{ "token": "Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI" }''
'
- lang: java
label: java
source: 'AuthleteConfiguration conf = ...;
AuthleteApi api = AuthleteApiFactory.create(conf);
UserInfoIssueRequest req = new UserInfoIssueRequest();
req.setToken("Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI");
api.userinfoIssue(req);
'
- lang: python
source: 'conf = ...
api = AuthleteApiImpl(conf)
req = UserInfoIssueRequest()
req.token = ''Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI''
api.userinfoIssue(req)
'
tags:
- UserInfo Endpoint
components:
responses:
'401':
description: ''
content:
application/json:
schema:
$ref: '#/components/schemas/result'
example:
resultCode: A001202
resultMessage: '[A001202] /auth/authorization, Authorization header is missing.'
'400':
description: ''
content:
application/json:
schema:
$ref: '#/components/schemas/result'
example:
resultCode: A001201
resultMessage: '[A001201] /auth/authorization, TLS must be used.'
'500':
description: ''
content:
application/json:
schema:
$ref: '#/components/schemas/result'
example:
resultCode: A001101
resultMessage: '[A001101] /auth/authorization, Authlete Server error.'
'403':
description: ''
content:
application/json:
schema:
$ref: '#/components/schemas/result'
example:
resultCode: A001215
resultMessage: '[A001215] /auth/authorization, The client (ID = 26837717140341) is locked.'
schemas:
userinfo_issue_request:
type: object
required:
- token
properties:
token:
type: string
description: 'The access token that has been passed to the userinfo endpoint by the client application. In other words,
the access token which was contained in the userinfo request.
'
claims:
type: string
description: 'Claims in JSON format. As for the format, see [OpenID Connect Core 1.0, 5.1. Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims).
'
sub:
type: string
description: 'The value of the `sub` claim. 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 associated with the access token is used.
'
claimsForTx:
type: string
description: 'Claim key-value pairs that are used to compute transformed claims.
'
requestSignature:
type: string
description: 'The Signature header value from the request.
'
headers:
type: array
items:
$ref: '#/components/schemas/pair'
description: 'HTTP headers to be included in processing the signature. If this is a signed request, this must include the
Signature and Signature-Input headers, as well as any additional headers covered by the signature.
'
verifiedClaimsForTx:
type: array
items:
type: string
description: 'Values of verified claims requested indirectly by "transformed claims".
'
x-mint:
metadata:
description: Values of verified claims requested indirectly by "transformed claims".
content: "<Accordion title=\"Full description\" defaultOpen={false}>\nA client application may request \"transformed claims\". Each of transformed claims uses an existing\nclaim as input. As a result, to compute the value of a transformed claim, the value of the referenced\nexisting claim is needed. This `verifiedClaimsForTx` request parameter has to be used to provide\nvalues of existing claims for computation of transformed claims.\n\nA response from the `/auth/userinfo` API may include the `requestedVerifiedClaimsForTx` response\nparameter which is a list of verified claims that are referenced indirectly by transformed claims\n(cf. `requestedVerifiedClaimsForTx` in `/auth/userinfo` API response). The authorization server\nimplementation should prepare values of the verified claims listed in `requestedVerifiedClaimsForTx`\nand pass them as the value of this `verifiedClaimsForTx` request parameter.\n\nThe following is an example of the value of this request parameter.\n\n```\n[\n \"{\\\"birthdate\\\":\\\"1970-01-23\\\",\\\"nationalities\\\":[\\\"DEU\\\",\\\"USA\\\"]}\"\n]\n```\n\nThe reason that this `verifiedClaimsForTx` property is an array is that the `\"verified_claims\"`\nproperty in the claims request parameter of an authorization request can be an array like below.\n\n```\n{\n \"transformed_claims\": {\n \"nationality_usa\": {\n \"claim\": \"nationalities\",\n \"fn\": [\n [ \"eq\", \"USA\" ],\n \"any\"\n ]\n }\n },\n \"userinfo\": {\n \"verified_claims\": [\n {\n \"verification\": { \"trust_framework\": { \"value\": \"gold\" } },\n \"claims\": { \"::18_or_above\": null }\n },\n {\n \"verification\": { \"trust_framework\": { \"value\": \"silver\" } },\n \"claims\": { \":nationality_usa\": null }\n }\n ]\n }\n}\n```\n\nFor the example above, the value of this `verifiedClaimsForTx` property should be an array of\nsize 2 and look like below. The first element is JSON including claims which have been verified\nunder the trust framework `\"gold\"`, and the second element is JSON including claims which have\nbeen verified under the trust framework `\"silver\"`.\n\n```\n[\n \"{\\\"birthdate\\\":\\\"1970-01-23\\\"}\",\n \"{\\\"nationalities\\\":[\\\"DEU\\\",\\\"USA\\\"]}\"\n]\n```\n</Accordion>\n"
userinfo_response:
type: object
properties:
resultCode:
type: string
description: The code which represents the result of the API call.
resultMessage:
type: string
description: A short message which explains the result of the API call.
action:
type: string
enum:
- INTERNAL_SERVER_ERROR
- BAD_REQUEST
- UNAUTHORIZED
- FORBIDDEN
- OK
description: The next action that the authorization server implementation should take.
claims:
type: array
items:
type: string
description: 'The list of claims that the client application requests to be embedded in the ID token.
'
clientId:
type: integer
format: int64
description: 'The ID of the client application which is associated with the access token.
'
clientIdAlias:
type: string
description: 'The client ID alias when the authorization request for the access token was made.
'
clientIdAliasUsed:
type: boolean
description: 'The flag which indicates whether the client ID alias was used when the authorization
request for the access token was made.
'
responseContent:
type: string
description: 'The content that the authorization server implementation can use as the value of `WWW-Authenticate`
header on errors.
'
scopes:
type: array
items:
type: string
description: 'The scopes covered by the access token.
'
subject:
type: string
description: 'The subject (= resource owner''s ID).
'
token:
type: string
description: 'The access token that came along with the userinfo request.
'
properties:
type: array
items:
$ref: '#/components/schemas/property'
description: 'The extra properties associated with the access token.
'
userInfoClaims:
type: string
description: 'The value of the `userinfo` property in the `claims` request parameter or in the `claims` property in an authorization request object.
'
x-mint:
metadata:
description: The value of the `userinfo` property in the `claims` request parameter or in the `claims` property in an authorization request object.
content: "<Accordion title=\"Full description\" defaultOpen={false}>\nA client application may request certain claims be embedded in an ID token or in a response from the userInfo endpoint.\nThere are several ways. Including the `claims` request parameter and including the `claims` property in a request object are such examples.\nIn both cases, the value of the `claims`
# --- truncated at 32 KB (47 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/authlete/refs/heads/main/openapi/authlete-userinfo-endpoint-api-openapi.yml