Create access tokens in batch.
Authenticate every request with a Service Access Token or Organization Token.
Set the token value in the Authorization: Bearer <token> header.
Service Access Token: Scoped to a single service. Use when automating service-level configuration or runtime flows.
Organization Token: Scoped to the organization; inherits permissions across services. Use for org-wide automation or when managing multiple services programmatically.
Both token types are issued by the Authlete console or provisioning APIs.
A service ID.
If true, the request is processed but access tokens are not actually created.
The grant type of the access token when the access token was created.
AUTHORIZATION_CODE, IMPLICIT, PASSWORD, CLIENT_CREDENTIALS, REFRESH_TOKEN, CIBA, DEVICE_CODE, TOKEN_EXCHANGE, JWT_BEARER, PRE_AUTHORIZED_CODE The ID of the client application which will be associated with a newly created access token.
The subject (= unique identifier) of the user who will be associated with a newly created access
token. This parameter is required unless the grant type is CLIENT_CREDENTIALS. The value must
consist of only ASCII characters and its length must not exceed 100.
The scopes which will be associated with a newly created access token. Scopes that are not supported by the service cannot be specified and requesting them will cause an error.
The duration of a newly created access token in seconds. If the value is 0, the duration is determined according to the settings of the service.
The duration of a newly created refresh token in seconds. If the value is 0, the duration is determined according to the settings of the service.
A refresh token is not created (1) if the service does not support REFRESH_TOKEN, or (2) if the
specified grant type is either IMPLICITor CLIENT_CREDENTIALS.
Extra properties to associate with a newly created access token. Note that properties parameter
is accepted only when the HTTP method of the request is POST and Content-Type of the request is
application/json, so don't use GET method or application/x-www-form-urlencoded if you want
to specify properties.
A boolean request parameter which indicates whether to emulate that the client ID alias is used instead of the original numeric client ID when a new access token is created.
This has an effect only on the value of the aud claim in a response from UserInfo endpoint.
When you access the UserInfo endpoint (which is expected to be implemented using Authlete's
/api/auth/userinfo API and /api/auth/userinfo/issue API) with an access token which has been
created using Authlete's /api/auth/token/create API with this property (clientIdAliasUsed)
true, the client ID alias is used as the value of the aud claim in a response from the UserInfo
endpoint.
Note that if a client ID alias is not assigned to the client when Authlete's /api/auth/token/create
API is called, this property (clientIdAliasUsed) has no effect (it is always regarded as false).
The value of the new access token.
The /api/auth/token/create API generates an access token. Therefore, callers of the API do not
have to specify values of newly created access tokens. However, in some cases, for example, if
you want to migrate existing access tokens from an old system to Authlete, you may want to specify
values of access tokens. In such a case, you can specify the value of a newly created access token
by passing a non-null value as the value of accessToken request parameter. The implementation
of the /api/auth/token/create uses the value of the accessToken request parameter instead of
generating a new value when the request parameter holds a non-null value.
Note that if the hash value of the specified access token already exists in Authlete's database,
the access token cannot be inserted and the /api/auth/token/create API will report an error.
The value of the new refresh token.
The /api/auth/token/create API may generate a refresh token. Therefore, callers of the API do
not have to specify values of newly created refresh tokens. However, in some cases, for example,
if you want to migrate existing refresh tokens from an old system to Authlete, you may want to
specify values of refresh tokens. In such a case, you can specify the value of a newly created
refresh token by passing a non-null value as the value of refreshToken request parameter. The
implementation of the /api/auth/token/create uses the value of the refreshToken request parameter
instead of generating a new value when the request parameter holds a non-null value.
Note that if the hash value of the specified refresh token already exists in Authlete's database,
the refresh token cannot be inserted and the /api/auth/token/create API will report an error.
Get whether the access token expires or not. By default, all access tokens expire after a period of time determined by their service.
If this request parameter is true, then the access token will not automatically expire and must
be revoked or deleted manually at the service. If this request parameter is true, the accessTokenDuration
request parameter is ignored.
The thumbprint of the MTLS certificate bound to this token. If this property is set, a certificate with the corresponding value MUST be presented with the access token when it is used by a client. The value of this property must be a SHA256 certificate thumbprint, base64url encoded.
The thumbprint of the public key used for DPoP presentation of this token. If this property is
set, a DPoP proof signed with the corresponding private key MUST be presented with the access
token when it is used by a client. Additionally, the token's token_type will be set to 'DPoP'.
The authorization details. This represents the value of the authorization_details
request parameter in the preceding device authorization request which is defined in
"OAuth 2.0 Rich Authorization Requests".
The value of the resources to associate with the token. This property represents the value of
one or more resource request parameters which is defined in "RFC8707 Resource Indicators for
OAuth 2.0".
the flag which indicates whether the access token is for an external attachment.
Additional claims that are added to the payload part of the JWT access token.
The Authentication Context Class Reference of the user authentication that the authorization server performed during the course of issuing the access token.
The time when the user authentication was performed during the course of issuing the access token.
Flag which indicates whether the entity ID of the client was used when the request for the access token was made.
The client Identifier associated with the newly issued access token.
The session ID, which is the ID of the user's authentication session, associated with a newly created access token.
Flag indicating whether a metadata document was used to resolve client metadata for this request.
When true, the client metadata was retrieved via the OAuth Client ID Metadata Document (CIMD) mechanism rather than from the Authlete database.