• TLS is not used.
• The content of Authorization header is malformed.

• Authorization header is missing.

• The pair of API key & API secret specified in Authorization header is invalid.
• The service owner or the service is locked.

The hash of the access token.

The timestamp at which the access token will expire.

The hash of the refresh token.

The timestamp at which the refresh token will expire.

The timestamp at which the access token was first created.

The timestamp at which the access token was last refreshed using the refresh token.

The ID of the client associated with the access token.

The subject (= unique user ID) associated with the access token.

The grant type of the access token when the access token was created.

The scopes associated with the access token.

The properties associated with the access token.

This value corresponds to "none" described in OpenID Connect Core 1.0, 9. Client Authentication.

This value corresponds to "client_secret_basic" described in OpenID Connect Core 1.0, 9. Client Authentication. This is the Basic Authentication based method described in RFC 6749, 2.3. Client Authentication, which authorization servers must support.

This value corresponds to "client_secret_post" described in OpenID Connect Core 1.0, 9. Client Authentication. This is the method using the request body, which is described in RFC 6749, 2.3. Client Authentication.

This value corresponds to "client_secret_jwt" described in OpenID Connect Core 1.0, 9. Client Authentication.

This value corresponds to "private_key_jwt" described in OpenID Connect Core 1.0, 9. Client Authentication.

Clients authenticate with the Authorization Server using X.509 certificates as defined in "Mutual TLS Profiles for OAuth Clients".

Clients authenticate with the Authorization Server using self-signed certificates as defined in "Mutual TLS Profiles for OAuth Clients".

The set of scopes that the client application is allowed to request. This paramter will be one of the following.

• null
• an empty set
• a set with at least one element

When the value of this parameter is null, it means that the set of scopes that the client application is allowed to request is the set of the scopes that the service supports.

When the value of this parameter is an empty set, it means that the client application is not allowed to request any scopes.

When the value of this parameter is a set with at least one element, it means that the set is the set of scopes that the client application is allowed to request.

The flag to indicate whether "Requestable Scopes per Client" is enabled or not. If true, you can define the set of scopes which this client application can request. If false, this client application can request any scope which is supported by the authorization server.

The sequential number of the client application. The value of this property is assigned by Authlete. Even if the property has a value in a /client/create request or a /client/update request, it is ignored.

The sequential number of the service of the client application. The value of this property is assigned by Authlete. Even if the property has a value in a /client/create request or a /client/update request, it is ignored.

The developer of the client application. It consists of at most 100 ASCII letters. This property must not be null.

The client ID. The value of this property is assigned by Authlete. Even if the property has a value in a /client/create request or a /client/update request, it is ignored.

The alias of the client ID. Note that the client ID alias is recognized only when this client's clientIdAliasEnabled property is true AND the service's clientIdAliasEnabled property is also true.

The flag to indicate whether the client ID alias is enabled or not. Note that Service object also has clientIdAliasEnabled property. If the service's clientIdAliasEnabled property is false, the client ID alias of this client is not recognized even if this client's clientIdAliasEnabled property is true.

The client secret. A random 512-bit value encoded by base64url (86 letters). The value of this property is assigned by Authlete. Even if the property has a value in a /client/create request or a /client/update request, it is ignored.

Note that Authlete issues a client secret even to a "public" client application, but the client application should not use the client secret unless it changes its client type to "confidential". That is, a public client application should behave as if it had not been issued a client secret. To be specific, a token request from a public client of Authlete should not come along with a client secret although RFC 6749, 3.2.1. Client Authentication says as follows.

The client type, either CONFIDENTIAL or PUBLIC. See RFC 6749, 2.1. Client Types for details.

If clientType in a /client/create request or a /client/update request is null, PUBLIC is used.

Redirect URIs that the client application uses to receive a response from the authorization endpoint. Requirements for a redirect URI are as follows.

Requirements by RFC 6749

(From RFC 6749, 3.1.2. Redirection Endpoint)

• Must be an absolute URI.
• Must not have a fragment component.

Requirements by OpenID Connect

(From "OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata, application_type")

• The scheme of the redirect URI used for Implicit Grant by a client application whose application type is "web" must be https. This is checked at runtime by Authlete.
• The hostname of the redirect URI used for Implicit Grant by a client application whose application type is "web" must not be localhost. This is checked at runtime by Authlete.
• The scheme of the redirect URI used by a client application whose application type is "native" must be either (1) a custom scheme or (2) http, which is allowed only when the hostname part is localhost. This is checked at runtime by Authlete.

Requirements by Authlete

• Must consist of printable ASCII letters only.
• Must not exceed 200 letters.

Note that Authlete allows the application type to be null. In other words, a client application does not have to choose "web" or "native" as its application type. If the application type is null, the requirements by OpenID Connect are not checked at runtime.

An authorization request from a client application which has not registered any redirect URI fails unless at least all the following conditions are satisfied.

• The client type of the client application is "confidential".
• The value of response_type request parameter is code.
• The authorization request has the redirect_uri request parameter.
• The value of scope request parameter does not contain openid.

RFC 6749 allows partial match of redirect URI under some conditions (see RFC 6749, 3.1.2.2. Registration Requirements for details), but OpenID Connect requires exact match.

A string array of response types which the client application declares that it will restrict itself to using. This property corresponds to response_types in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

If responseTypes in a /client/create request or a /client/update request is null, an array containing just CODE is used.

A string array of grant types which the client application declares that it will restrict itself to using. This property corresponds to grant_types in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

If grantTypes in a /client/create request or a /client/update request is null, an array containing just AUTHORIZATION_CODE is used.

The application type. WEB, NATIVE or null. The value of this property affects the validation steps for a redirect URI. See the description about redirectUris property above.

This property corresponds to application_type in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

An array of email addresses of people responsible for the client application. Each element must consist of printable ASCII letters only and its length must not exceed 100.

This property corresponds to contacts in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The name of the client application. At most 100 unicode letters.

If clientName in a /client/create request or a /client/update request is null, the client ID is used.

This property corresponds to client_name in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

Client names with language tags. If the client application has different names for different languages, this property can be used to register the names.

The URL pointing to the logo image of the client application. The URL must consist of printable ASCII letters only and its length must not exceed 200.

This property corresponds to logo_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

Logo image URLs with language tags. If the client application has different logo images for different languages, this property can be used to register URLs of the images.

The URL pointing to the home page of the client application. The URL must consist of printable ASCII letters only and its length must not exceed 200.

This property corresponds to client_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

Home page URLs with language tags. If the client application has different home pages for different languages, this property can be used to register the URLs.

The URL pointing to the page which describes the policy as to how end-users' profile data are used. The URL must consist of printable ASCII letters only and its length must not exceed 200.

This property corresponds to policy_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

URLs of policy pages with language tags. If the client application has different policy pages for different languages, this property can be used to register the URLs.

The URL pointing to the "Terms Of Service" page. The URL must consist of printable ASCII letters only and its length must not exceed 200.

This property corresponds to tos_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

URLs of "Terms Of Service" pages with language tags. If the client application has different "Terms Of Service" pages for different languages, this property can be used to register the URLs.

The URL pointing to the JWK Set of the client application. The URL must consist of printable ASCII letters only and its length must not exceed 200. The content pointed to by the URL must be JSON which complies with the format described in "JSON Web Key (JWK), 5. JSON Web Key Set (JWK Set) Format". Of course, the JWK Set must not include private keys of the client application.

If the client application requests encryption for ID tokens (from the authorization/token/userinfo endpoints) and/or signs request objects, it must make available its JWK Set containing public keys for the encryption and/or the signature at the URL of jwksUri. The service (Authlete) fetches the JWK Set from the URL as necessary.

OpenID Connect Dynamic Client Registration 1.0 says that jwks must not be used when the client can use jwks_uri, but Authlete allows both properties to be registered at the same time. However, Authlete does not use the content of jwks when jwksUri is registered.

This property corresponds to jwks_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The content of the JWK Set of the client application. The format is described in "JSON Web Key (JWK), 5. JSON Web Key Set (JWK Set) Format". Of course, the JWK Set must not include private keys of the client application.

OpenID Connect Dynamic Client Registration 1.0 says that jwks must not be used when the client can use jwks_uri, but Authlete allows both properties to be registered at the same time. However, Authlete does not use the content of jwks when jwksUri is registered.

This property corresponds to jwks in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The sector identifier which is a URL starting with https. The URL must consist of printable ASCII letters only and its length must not exceed 200.This URL is used by the service to calculate pairwise subject values. See OpenID Connect Core 1.0, 8.1. Pairwise Identifier Algorithm. Note that, however, Authlete does not support pairwise yet.

This property corresponds to sector_identifier_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The subject type that the client application requests. Either PUBLIC or PAIRWISE. the default value is PUBLIC. Details about the subject type are described in OpenID Connect Core 1.0, 8. Subjct Identifier Types.

Because Authlete's implementation for PAIRWISE is not finished yet, even if subjectType configuration parameter of the client application is PAIRWISE, Authlete behaves as if it were PUBLIC.

This property corresponds to subject_type in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of alg header parameter of JWS that the client application requires the service to use for signing an ID token. One of the values listed in JWS Algorithm. The default value is RS256.

NONE may be specified, but in that case, the client application cannot obtain an ID token from the service. That is, an authorization request requesting an ID token fails.

This property corresponds to id_token_signed_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of alg header parameter of JWE that the client application requires the service to use for encrypting an ID token. One of the supported values listed in JWE Algorithm. The default value is null, meaning that an ID token is not encrypted. When idTokenEncryptionEnc is not null, this property must not be null.

If the value of this property indicates an asymmetric encryption algorithm, the client application must make available its JWK Set which contains a public key for encryption at the URL referred to by its jwksUri configuration property.

This property corresponds to id_token_encrypted_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of enc header parameter of JWE that the client application requires the service to use for encrypting an ID token. One of the values listed in JWE Encryption Algorithm. The default value is (1) A128CBC_HS256 when idTokenEncryptionAlg is not null, or (2) null when idTokenEncryptionAlg is null.

This property corresponds to id_token_encrypted_response_enc in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of alg header parameter of JWS that the client application requires the service to use for signing the JWT returned from the user info endpoint. One of the values listed in JWS Algorithm. The default value is null, meaning that the data from the user info endpoint is not signed.

If both userInfoSignAlg and userInfoEncryptionAlg are null, the format of the response from the user info endpoint is a plain JSON (not JWT). Note that null and NONE are different for this property.

This property corresponds to userinfo_signed_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of alg header parameter of JWE that the client application requires the service to use for encrypting the JWT returned from the user info endpoint. One of the supported values listed in JWE Algorithm. The default value is null, meaning that the data from the user info endpoint is not encrypted. When userInfoEncryptionEnc is not null, this property must not be null.

If the value of this property indicates an asymmetric encryption algorithm, the client application must make available its JWK Set which contains a public key for encryption at the URL referred to by its jwksUri configuration property.

If both userInfoSignAlg and userInfoEncryptionAlg are null, the format of the response from the user info endpoint is a plain JSON (not JWT).

This property corresponds to userinfo_encrypted_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of enc header parameter of JWE that the client application requires the service to use for encrypting the JWT returned from the user info endpoint. One of the values listed in JWE Encryption Algorithm. The default value is (1) A128CBC_HS256 when userInfoEncryptionAlg is not null, or (2) null when userInfoEncryptionAlg is null.

This property corresponds to userinfo_encrypted_response_enc in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of alg header parameter of JWS that the client application uses for signing a request object. One of the values listed in JWS Algorithm. The default value is null, meaning that the client application may use any algorithm (among those supported by the service) to sign a request object (including none).

If the value of this property is not null, request objects sent from the client application must be signed using the algorithm. Request objects signed by other algorithms are rejected. Note that null and NONE are different for this property.

If the value of this property indicates an asymmetric signing algorithm, the client application must make available its JWK Set which contains a public key for the service to verify the signature of the request object at the URL referred to by its jwksUri configuration property.

This property corresponds to request_object_signing_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of alg header parameter of JWE that the client application uses for encrypting a request object. One of the supported values listed in JWE Algorithm. The default value is null. When requestEncryptionEnc is not null, this property must not be null.

Regardless of whether the value of this property is null or not, the client application may and may not encrypt a request object. Furthermore, the client application may use other supported encryption algorithms.

This property corresponds to request_object_encryption_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of enc header parameter of JWE that the client application uses for encrypting a request object. One of the values listed in JWE Encryption Algorithm. The default value is (1) A128CBC_HS256 when requestEncryptionAlg is not null, or (2) null when requestEncryptionAlg is null.

This property corresponds to request_object_encryption_enc in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The client authentication method that the client application declares that it uses at the token endpoint. One of the values listed in Client Authentication Method. The default value is CLIENT_SECRET_BASIC (if Authlete version < 2.0) or NONE (if Authlete version ≥ 2.0).

This property corresponds to token_endpoint_auth_method in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The value of alg header parameter of JWS which is used for client authentication at the token endpoint. One of the values listed in JWS Algorithm except NONE. The default value is null, meaning that the client may sign using any algorithm which is supported by the service. If the value of this property is not null, the client application must use the algorithm.

This property is used only for the two JWT-based client authentication, namely, PRIVATE_KEY_JWT and CLIENT_SECRET_JWT (see Cient Authentication Method). Note that, however, currently Authlete does not provide any API to help implementations for PRIVATE_KEY_JWT and CLIENT_SECRET_JWT.

This property corresponds to token_endpoint_auth_signing_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The default maximum authentication age in seconds. This value is used when an authorization request from the client application does not have max_age request parameter.

This property corresponds to default_max_age in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The default ACRs (Authentication Context Class References). This value is used when an authorization request from the client application has neither acr_values request parameter nor acr claim in claims request parameter.

Each element must consist of printable ASCII letters only and its length must not exceed 200.

true if the client application requires the auth_time claim to be in an ID token. Regardless of the value of this property, Authlete embeds the auth_time claim when authTime parameter in the /auth/authorization/issue request is not 0 and does not do it when authTime is 0.

This property corresponds to require_auth_time in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

The URL which a third party can use to initiate a login by the client application. The URL must start with https and consist of ASCII letters only. Its length must not exceed 200.

This property corresponds to initiate_login_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

An array of URLs each of which points to a request object. Each URL must consist of printable ASCII letters only and its length must not exceed 200.

Authlete requires that URLs used as values for request_uri request parameter be pre-registered. This requestUris property is used for the pre-registration. See OpenID Connect Core 1.0, 6.2. Passing a Request Object by Reference for details.

The description about the client application. At most 200 letters in unicode.

Descriptions about the client application with language tags. If the client application has different descriptions for different languages, this property can be used to register the descriptions.

The time at which this client was created. The value is represented as milliseconds since the UNIX epoch (1970-01-01).

The time at which this client was last modified. The value is represented as milliseconds since the UNIX epoch (1970-01-01).

The extended information about this client.

The string representation of the expected subject distinguished name of the certificate this client will use in mutual TLS authentication.

See tls_client_auth_subject_dn in "2.3. Dynamic Client Registration" in "Mutual TLS Profiles for OAuth Clients" for details.

The string representation of the expected DNS subject alternative name of the certificate this client will use in mutual TLS authentication.

See tls_client_auth_san_dns in "2.3. Dynamic Client Registration" in "Mutual TLS Profiles for OAuth Clients" for details.

The string representation of the expected URI subject alternative name of the certificate this client will use in mutual TLS authentication.

See tls_client_auth_san_uri in "2.3. Dynamic Client Registration" in "Mutual TLS Profiles for OAuth Clients" for details.

The string representation of the expected IP address subject alternative name of the certificate this client will use in mutual TLS authentication.

See tls_client_auth_san_ip in "2.3. Dynamic Client Registration" in "Mutual TLS Profiles for OAuth Clients" for details.

The string representation of the expected email address subject alternative name of the certificate this client will use in mutual TLS authentication.

See tls_client_auth_san_email in "2.3. Dynamic Client Registration" in "Mutual TLS Profiles for OAuth Clients" for details.

The flag which indicates whether this client use TLS client certificate bound access tokens.

The key ID of a JWK containing a self-signed certificate of this client.

The unique identifier string assigned by the client developer or software publisher used by registration endpoints to identify the client software to be dynamically registered.

This property corresponds to the software_id metadata defined in 2. Client Metadata of RFC 7591 (OAuth 2.0 Dynamic Client Registration Protocol).

The version identifier string for the client software identified by the software ID.

This property corresponds to the software_version metadata defined in 2. Client Metadata of RFC 7591 (OAuth 2.0 Dynamic Client Registration Protocol).

The JWS alg algorithm for signing authorization responses. One of the values listed in JWS Algorithm. The default value is null.

This property corresponds to authorization_signed_response_alg in 5. Client Metadata of Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM).

The JWE alg algorithm for encrypting authorization responses. One of the values listed in JWE Algorithm. The default value is null. When authorizationEncryptionEnc is not null, this property must not be null.

This property corresponds to authorization_encrypted_response_alg in 5. Client Metadata of Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM).

The JWE enc algorithm for encrypting authorization responses. The default value is null.

This property corresponds to authorization_encrypted_response_enc in 5. Client Metadata of Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM).

The backchannel token delivery mode.

This property corresponds to the backchannel_token_delivery_mode metadata. One of the values listed in Delivery Mode. The backchannel token delivery mode is defined in the specification of the CIBA (Client Initiated Backchannel Authentication).

The backchannel client notification endpoint.

This property corresponds to the backchannel_client_notification_endpoint metadata. The backchannel token delivery mode is defined in the specification of the CIBA (Client Initiated Backchannel Authentication).

The signature algorithm of the request to the backchannel authentication endpoint. One of the asymmetric algorithm values listed in JWS Algorithm. The default value is null.

This property corresponds to the backchannel_authentication_request_signing_alg metadata. The backchannel token delivery mode is defined in the specification of the CIBA (Client Initiated Backchannel Authentication).

The boolean flag which indicates whether a user code is required when this client makes a backchannel authentication request.

This property corresponds to the backchannel_user_code_parameter metadata.

The flag which indicates whether this client has been registered dynamically.

The hash of the registration access token for this client.

This corresponds to "authorization_code" defined in RFC 6749, 4.1.3. Access Token Request for Authorization Code Grant.

This corresponds to "implicit" defined in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata for Implicit Grant.

This corresponds to "password" defined in RFC 6749, 4.3.2. Access Token Request for Resource Owner Password Credentials Grant.

This corresponds to "client_credentials" defined in RFC 6749, 4.4.2. Access Token Request for Client Credentials Grant.

This corresponds to "refresh_token" defined in RFC 6749, 6. Refreshing an Access Token.

The key part.

The value part.

The key part.

The value part.

The flag to indicate whether this property hidden from or visible to client applications.

If true, this property is hidden from client applications. Otherwise, this property is visible to client applications.

This corresponds to "none" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 4. None Response Type.

This corresponds to "code" defined in RFC 6749, 4.1.1. Authorization Request for Authorization Code Grant.

This corresponds to "token" defined in RFC 6749, 4.2.1. Authorization Request for Implicit Grant.

This corresponds to "id_token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 3. ID Token Response Type.

This corresponds to "code token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 5. Definitions of Multiple-Valued Response Type Combinations.

This corresponds to "code id_token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 5. Definitions of Multiple-Valued Response Type Combinations.

This corresponds to "id_token token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 5. Definitions of Multiple-Valued Response Type Combinations.

This corresponds to "code id_token token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 5. Definitions of Multiple-Valued Response Type Combinations.

The name of the scope. Letters that can be used for a scope name are %x21, %x23-5B and %x5D-7E. Put simply, they are printable ASCII letters excluding "space (%x20)", "double quotation mark (%x22)" and "backslash (%x5C)". Its length must not exceed 200.

true to mark the scope as default. Scopes marked as default are regarded as requested when an authorization request from a client application does not contain scope request parameter.

OPTIONAL. The description of the scope. It is a unicode string. Its length must not exceed 200.

OPTIONAL. The attributes of the scope.

The sequential number of the service. The value of this property is assigned by Authlete. Even if the property has a value in a /service/create request or a /service/update request, it is ignored.

The sequential number of the service owner of the service. The value of this property is assigned by Authlete. Even if the property has a value in a /service/create request or a /service/update request, it is ignored.

The name of the service. It consists of at most 100 unicode letters. This property may be null.

The API key. The value of this property is assigned by Authlete. Even if the property has a value in a /service/create request or a /service/update request, it is ignored.

The API secret. A random 256-bit value encoded by base64url (43 letters). The value of this property is assigned by Authlete. Even if the property has a value in a /service/create request or a /service/update request, it is ignored.

The issuer identifier of the service. A URL that starts with https:// and has no query or fragment component. For example, https://example.com. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null.

The value of this property is used as iss claim in an ID token and issuer property in the OpenID Provider Metadata.

The authorization endpoint of the service. A URL that starts with https:// and has no fragment component. For example, https://example.com/auth/authorization. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null.

The value of this property is used as authorization_endpoint property in the OpenID Provider Metadata.

The token endpoint of the service. A URL that starts with https:// and has not fragment component. For example, https://example.com/auth/token. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null if and only if the service supports only Implicit Grant (= supports response_type=token only).

The value of this property is used as token_endpoint property in the OpenID Provider Metadata.

The revocation endpoint of the service. A URL that starts with https://. For example, https://example.com/auth/revocation. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null if the service does not support the revocation endpoint.

The user info endpoint of the service. A URL that starts with https://. For example, https://example.com/auth/userinfo. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null if the service does not support the user info endpoint.

The value of this property is used as userinfo_endpoint property in the OpenID Provider Metadata.

The URL of the service's JSON Web Key Set document. For example, http://example.com/auth/jwks. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null if and only if the service does not support asymmetric signatures for ID tokens and asymmetric encryption for request objects.

Client applications accesses this URL (1) to get the public key of the service to validate the signature of an ID token issued by the service and (2) to get the public key of the service to encrypt an request object of the client application. See OpenID Connect Core 1.0, 10. Signatures and Encryption for details.

The value of this property is used as jwks_uri property in the OpenID Provider Metadata.

The content of the service's JSON Web Key Set document. If this property is not null in a /service/create request or a /service/update, Authlete hosts the content in the database. This property must not be null and must contain pairs of public/private keys if the service wants to support asymmetric signatures for ID tokens and asymmetric encryption for request objects. See OpenID Connect Core 1.0, 10. Signatures and Encryption for details.

The registration endpoint of the service. A URL that starts with https://. For example, https://example.com/auth/registration. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200.

The value of this property is used as registration_endpoint property in the OpenID Provider Metadata.

The URI of the registration management endpoint. If dynamic client registration is supported, and this is set, this URI will be used as the basis of the client's management endpoint by appending /clientid/ to it as a path element. If this is unset, the value of registrationEndpoint will be used as the URI base instead.

Scopes supported by the service. Authlete strongly recommends that the service register at least the following scopes.

The value of this property is used as scopes_supported property in the OpenID Provider Metadata.

Values of response_type request parameter that the service supports. Valid values are listed in Response Type.

The value of this property is used as response_types_supported property in the OpenID Provider Metadata.

Values of grant_type request parameter that the service supports. Valid values are listed in Grant Type.

The value of this property is used as grant_types_supported property in the OpenID Provider Metadata.

Values of Authentication Context Class References that the service supports.

The value of this property is used as acr_values_supported property in the OpenID Provider Metadata.

Client authentication methods supported by the token endpoint of the service. Valid values are listed in Client Authentication Method. Note that, however, currently Authlete does not provide any API to help implementations for CLIENT_SECRET_JWT and PRIVATE_KEY_JWT.

The value of this property is used as token_endpoint_auth_methods_supports property in the OpenID Provider Metadata.

Values of display request parameter that service supports. Valid values are listed in Display.

The value of this property is used as display_values_supported property in the OpenID Provider Metadata.

Claim types supported by the service. Valid values are listed in Claim Type. Note that, however, currently Authlete does not provide any API to help implementations for AGGREGATED and DISTRIBUTED.

The value of this property is used as claim_types_supported property in the OpenID Provider Metadata.

Claim names that the service supports. The standard claim names listed in OpenID Connect Core 1.0, 5.1. Standard Claim should be supported. The following is the list of standard claims.

1. sub
2. name
3. given_name
4. family_name
5. middle_name
6. nickname
7. preferred_username
8. profile
9. picture
10. website
11. email
12. email_verified
13. gender
14. birthdate
15. zoneinfo
16. locale
17. phone_number
18. phone_number_verified
19. address
20. updated_at

The value of this property is used as claims_supported property in the OpenID Provider Metadata.

The service may support its original claim names. See OpenID Connect Core 1.0, 5.1.2. Additional Claims. Note that Authlete requires that original claim names consist of only ASCII letters and its length not exceed 200.

The URL of a page where documents for developers can be found.

The value of this property is used as service_documentation property in the OpenID Provider Metadata.

Claim locales that the service supports. Each element is a language tag defined in RFC 5646. For example, "en-US" and "ja-JP". Authlete requires that each language tag consist of only ASCII letters and its length not exceed 30. See OpenID Connect Core 1.0, 5.2. Languages and Scripts for details.

The value of this property is used as claims_locales_supported property in the OpenID Provider Metadata.

UI locales that the service supports. Each element is a language tag defined in RFC 5646. For example, "en-US" and "ja-JP". Authlete requires that each language tag consist of only ASCII letters and its length not exceed 30.

The value of this property is used as ui_locales_supported property in the OpenID Provider Metadata.

The URL of the "Policy" of the service. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200.

The value of this property is used as op_policy_uri property in the OpenID Provider Metadata.

The URL of the "Terms Of Service" of the service. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200.

The value of this property is used as op_tos_uri property in the OpenID Provider Metadata.

A Web API endpoint for user authentication which is to be prepared on the service side. It must consist of only ASCII characters and its length must not exceed 200.

The endpoint must be implemented if you do not implement the UI at the authorization endpoint but use the one provided by Authlete. The user authentication at the authorization endpoint provided by Authlete is performed by making a POST request to this endpoint.

See 'Authentication Callback' for details.

API key for Basic authentication at the authentication callback endpoint. It must consist of only ASCII characters and its length must not exceed 100.

If the value is not empty, Authlete generates Authorization header for Basic authentication when making a request to the authentication callback endpoint.

API secret for Basic authentication at the authentication callback endpoint. It must consist of only ASCII characters and its length must not exceed 100.

SNSes you want to support 'social login' in the UI at the authorization endpoint provided by Authlete. You need to register a client application in each SNS that is set to this parameter and set Authlete server's /api/sns/redirection as the redirection endpoint of the client application.

SNS credentials which Authlete uses to make requests to SNSes. The format is JSON.

The time at which this service was created. The value is represented as milliseconds since the UNIX epoch (1970-01-01).

The time at which this service was last modified. The value is represented as milliseconds since the UNIX epoch (1970-01-01).

A Web API endpoint for developer authentication which is to be prepared on the server side. It must consist of only ASCII characters and its length must not exceed 200.

The endpoint must be implemented if you use Developer Console. The developer authentication at the login page of Developer Console is performed by making a POST request to this endpoint.

API key for Basic authentication at the developer authentication callback endpoint. It must consist of only ASCII characters and its length must not exceed 100.

If the value is not empty, Authlete generates Authorization header for Basic authentication when making a request to the developer authentication callback endpoint.

API secret for Basic authentication at the developer authentication callback endpoint. It must consist of only ASCII characters and its length must not exceed 100.

SNSes you want to support 'social login' in the login page of Developer Console provided by Authlete. You need to register a client application in each SNS checked here and set Authlete server's /api/developer/sns/redirection as the redirection endpoint of the client application.

SNS credentials which Authlete uses to make requests to SNSes. The format is JSON.

The maximum number of client applications that a developer is allowed to create. 0 means no limit.

The flag to indicate whether the direct authorization endpoint is enabled or not.

If true, the default implementation of the authorization endpoint of this service works. The URL of the endpoint is https://api.authlete.com/api/auth/authorization/direct/service-api-key.

If false, the endpoint returns 404 Not Found. In this case, you have to implement the authorization endpoint by yourself using Authlete's Web APIs such as /api/auth/authorization, /api/auth/authorization/issue and /api/auth/authorization/fail.

The flag to indicate whether the direct token endpoint is enabled or not.

If true, the default implementation of the token endpoint of this service works. The URL of the endpoint is https://api.authlete.com/api/auth/token/direct/service-api-key.

If false, the endpoint returns 404 Not Found. In this case, you have to implement the token endpoint by yourself using Authlete's Web APIs such as /api/auth/token, /api/auth/token/issue and /api/auth/token/fail.

The flag to indicate whether the direct revocation endpoint is enabled or not.

If true, the default implementation of the revocation endpoint (RFC 7009) of this service works. The URL of the endpoint is https://api.authlete.com/api/auth/revocation/direct/service-api-key.

If false, the endpoint returns 404 Not Found. In this case, if you want to provide a revocation endpoint to client applications, you have to implement the endpoint by yourself using Authlete's /api/auth/revocation API.

The flag to indicate whether the direct userinfo endpoint is enabled or not.

If true, the default implementation of the userinfo endpoint of this service works. The URL of the endpoint is https://api.authlete.com/api/auth/userinfo/direct/service-api-key.

If false, the endpoint returns 404 Not Found. In this case, if you want to provide a userinfo endpoint to client applications, you have to implement the endpoint by yourself using Authlete's /api/auth/userinfo API.

This feature is not implemented yet.

The flag to indicate whether the direct jwks endpoint is enabled or not.

If true, the default implementation of the jwk set endpoint of this service works. The URL of the endpoint is https://api.authlete.com/api/service/jwks/get/direct/service-api-key.

If false, the endpoint returns 404 Not Found. In this case, if you want to provide a JWK Set endpoint to client applications, you have to implement the endpoint by yourself using Authlete's /api/service/jwks/get API.

The flag to indicate whether the number of access tokens per subject (and per client) is at most one or can be more.

If true, an attempt to issue a new access token invalidates existing access tokens that are associated with the same subject and the same client.

Note that, however, attempts by Client Credentials Flow do not invalidate existing access tokens because access tokens issued by Client Credentials Flow are not associated with any end-user's subject. Also note that an attempt by Refresh Token Flow invalidates the coupled access token only and this invalidation is always performed regardless of whether the value of this setting item is true or false.

The flag to indicate whether the use of Proof Key for Code Exchange (PKCE) is always required for authorization requests by Authorization Code Flow.

If true, code_challenge request parameter is always required for authorization requests using Authorization Code Flow.

See RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) for details about code_challenge request parameter.

The flag to indicate whether a refresh token remains unchanged or gets renewed after its use.

If true, a refresh token used to get a new access token remains valid after its use. Otherwise, if false, a refresh token is invalidated after its use and a new refresh token is issued.

See RFC 6749 6. Refreshing an Access Token, as to how to get a new access token using a refresh token.

The flag to indicate whether the error_description response parameter is omitted.

According to RFC 6749, an authorization server may include the error_description response parameter in error responses.

If true, Authlete does not embed the error_description response parameter in error responses.

The flag to indicate whether the error_uri response parameter is omitted.

According to RFC 6749, an authorization server may include the error_uri response parameter in error responses.

If true, Authlete does not embed the error_uri response parameter in error responses.

The description about the service. It consists of at most 200 unicode letters.

The access token type. This value is used as the value of token_type property in access token responses. If this service complies with RFC 6750, the value of this property should be Bearer.

See RFC 6749 (OAuth 2.0), 7.1. Access Token Types for details.

The duration of access tokens in seconds. This value is used as the value of expires_in property in access token responses. expires_in is defined RFC 6749, 5.1. Successful Response.

The duration of refresh tokens in seconds. The related specifications have no requirements on refresh token duration, but Authlete sets expiration for refresh tokens.

The duration of ID tokens in seconds. This value is used to calculate the value of exp claim in an ID token.

The metadata of the service. The content of the returned array depends on contexts. The predefined service metadata is listed in the following table.

The key ID to identify a JWK used for ID token signature using an asymmetric key.

A JWK Set can be registered as a property of a Service. A JWK Set can contain 0 or more JWKs (See RFC 7517 for details about JWK). Authlete Server has to pick up one JWK for signature from the JWK Set when it generates an ID token and signature using an asymmetric key is required. Authlete Server searches the registered JWK Set for a JWK which satisfies conditions for ID token signature. If the number of JWK candidates which satisfy the conditions is 1, there is no problem. On the other hand, if there exist multiple candidates, a Key ID is needed to be specified so that Authlete Server can pick up one JWK from among the JWK candidates.

This idTokenSignatureKeyId property exists for the purpose described above. For key rotation (OpenID Connect Core 1.0, 10.1.1. Rotation of Asymmetric Signing Keys), this mechanism is needed.

The key ID to identify a JWK used for user info signature using an asymmetric key.

A JWK Set can be registered as a property of a Service. A JWK Set can contain 0 or more JWKs (See RFC 7517 for details about JWK). Authlete Server has to pick up one JWK for signature from the JWK Set when it is required to sign user info (which is returned from userinfo endpoint) using an asymmetric key. Authlete Server searches the registered JWK Set for a JWK which satisfies conditions for user info signature. If the number of JWK candidates which satisfy the conditions is 1, there is no problem. On the other hand, if there exist multiple candidates, a Key ID is needed to be specified so that Authlete Server can pick up one JWK from among the JWK candidates.

This userInfoSignatureKeyId property exists for the purpose described above. For key rotation (OpenID Connect Core 1.0, 10.1.1. Rotation of Asymmetric Signing Keys), this mechanism is needed.

The profiles that this service supports. One of the values listed in Service Profile.

The boolean flag which indicates whether this service supports issuing TLS client certificate bound access tokens.

The URI of the introspection endpoint.

Client authentication methods supported at the introspection endpoint. One of the values listed in Client Authentication Method.

The boolean flag which indicates whether this service validates certificate chains during PKI-based client mutual TLS authentication.

The list of root certificates trusted by this service for PKI-based client mutual TLS authentication.

The signature algorithm of access tokens. One of the values listed in JWS Algorithm except for symmetric algorithms (HS256, HS384 and HS512). When null is set, access tokens issued by this service are just random strings. On the other hand, when a non-null value is set, access tokens issued by this service are JWTs and the value set by this method is used as the signature algorithm of the JWTs.

This parameter is available since Authlete 2.1. Access tokens generated by older Authlete versions are always random strings.

The duration of access tokens in seconds; the value of expires_in in access token responses.

The duration of authorization response JWTs.

Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) defines new values for the response_mode request parameter. They are query.jwt, fragment.jwt, form_post.jwt and jwt. If one of them is specified as the response mode, response parameters from the authorization endpoint will be packed into a JWT. This property is used to compute the value of the exp claim of the JWT.

The key ID to identify a JWK used for signing authorization responses using an asymmetric key.

Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) defines new values for the response_mode request parameter. They are query.jwt, fragment.jwt, form_post.jwt and jwt. If one of them is specified as the response mode, response parameters from the authorization endpoint will be packed into a JWT. This property is used to compute the value of the exp claim of the JWT.

Authlete Server searches the JWK Set for a JWK which satisfies conditions for authorization response signature. If the number of JWK candidates which satisfy the conditions is 1, there is no problem. On the other hand, if there exist multiple candidates, a Key ID is needed to be specified so that Authlete Server can pick up one JWK from among the JWK candidates. This property exists to specify the key ID.

The supported backchannel token delivery modes. This property corresponds to the backchannel_token_delivery_modes_supported metadata.

Backchannel token delivery modes are defined in the specification of CIBA (Client Initiated Backchannel Authentication).

The URI of the backchannel authentication endpoint.

Backchannel token delivery modes are defined in the specification of CIBA (Client Initiated Backchannel Authentication).

The boolean flag which indicates whether the "user_code" request parameter is supported at the backchannel authentication endpoint. This property corresponds to the backchannel_user_code_parameter_supported metadata.

The duration of backchannel authentication request IDs issued from the backchannel authentication endpoint in seconds. This is used as the value of the expires_in property in responses from the backchannel authentication endpoint.

The minimum interval between polling requests to the token endpoint from client applications in seconds. This is used as the value of the interval property in responses from the backchannel authentication endpoint.

The allowable clock skew between the server and clients in seconds.

The clock skew is taken into consideration when time-related claims in a JWT (e.g. "exp", "iat", "nbf") are verified.

The boolean flag which indicates whether the dynamic client registration is supported.

The language tag part. It must consist of only ASCII letters. Its length must not exceed 30.

The value part. It is a unicode string, but some client properties put more restrictive limitations such as "ASCII only". Its length must not exceed 200.

When this profile is enabled, it indicates the service supports Financial-grade API - Part 1: Read-Only API Security Profile and Financial-grade API - Part 2: Read and Write API Security Profile. Note that you need to enable this profile and also properly configure the service to conform the service to FAPI requirements.

When this profile is enabled, it indicates the service supports "Open Banking Security Profile". Note that you need to enable this profile and FAPI profile and also properly configure the service to conform the service to Open Banking requirements.

The API key of the service to be retrieved.

The start index (inclusive) of the result set. The default value is 0. Must not be a negative number.

The end index (exclusive) of the result set. The default value is 5. Must not be a negative number.

The start index (inclusive) of the result set of the query.

The end index (exclusive) of the result set of the query.

The total number of services owned by the service owner. This is different from the number of services contained in the response.

An array of services.

The API key of the service to be deleted.