• 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.

The type of this element.

From "OAuth 2.0 Rich Authorization Requests": "The type of authorization data as a string. This field MAY define which other elements are allowed in the request. This element is REQUIRED."

The resources and/or resource servers

From "OAuth 2.0 Rich Authorization Requests": "An array of strings representing the location of the resource or resource server. This is typically composed of URIs."

The actions.

From "OAuth 2.0 Rich Authorization Requests": "An array of strings representing the kinds of actions to be taken at the resource. The values of the strings are determined by the API being protected."

The data types.

From "OAuth 2.0 Rich Authorization Requests": "An array of strings representing the kinds of data being requested from the resource."

The identifier of a specific resource.

From "OAuth 2.0 Rich Authorization Requests": "A string identifier indicating a specific resource available at the API."

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 is available since Authlete 2.0.

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

This is available since Authlete 2.0.

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

This is available since Authlete 2.0.

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

This is available since Authlete 2.0.

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 value of the duration of access tokens per client in seconds. In normal cases, the value of the service's accessTokenDuration property is used as the duration of access tokens issued by the service. However, if this accessTokenDuration property holds a non-zero positive number and its value is less than the duration configured by the service, the value is used as the duration of access tokens issued to the client application.

Note that the duration of access tokens can be controlled by the scope attribute access_token.duration, too. Authlete chooses the minimum value among the candidates.

This property is available since Authlete 2.1.

The value of the duration of refresh tokens per client in seconds. In normal cases, the value of the service's refreshTokenDuration property is used as the duration of refresh tokens issued by the service. However, if this refreshTokenDuration property holds a non-zero positive number and its value is less than the duration configured by the service, the value is used as the duration of refresh tokens issued to the client application.

Note that the duration of refresh tokens can be controlled by the scope attribute refresh_token.duration, too. Authlete chooses the minimum value among the candidates.

This property is available since Authlete 2.1.

The sequential number of the client application. The value of this property is assigned by Authlete.

The sequential number of the service of the client application. The value of this property is assigned by Authlete.

The developer of the client application.

The name of the client application.

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 description about the client application.

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 client ID. The value of this property is assigned by Authlete.

The client secret. A random 512-bit value encoded by base64url (86 letters). The value of this property is assigned by Authlete.

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 alias of the client ID.

Note that the client ID alias is recognized only when this client's clientIdAliasEnabled property is set to true AND the service's clientIdAliasEnabled property is also set to 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 set to false, the client ID alias of this client is not recognized even if this client's clientIdAliasEnabled property is set to true.

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

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 for more details.

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

The URL pointing to the logo image of the client application.

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.

An array of email addresses of people responsible for the client application.

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

The flag to indicate whether this client use TLS client certificate bound access tokens.

This property is available since Authlete 2.0.

The flag to indicate whether this client has been registered dynamically. For more details, see RFC 7591 (OAuth 2.0 Dynamic Client Registration Protocol).

This property is available since Authlete 2.1.

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).

This property is available since Authlete 2.1.

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).

This property is available since Authlete 2.1.

The hash of the registration access token for this client.

This property is available since Authlete 2.1.

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).

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.

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.

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.

The data types that this client may use as values of the type field in authorization_details.

This property corresponds to the authorization_data_types metadata. See "OAuth 2.0 Rich Authorization Requests" (RAR) for details.

This property is available since Authlete 2.2.

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

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).

This property is available since Authlete 2.1.

The JWE alg algorithm for encrypting authorization responses. One of the values listed in JWE Algorithm.

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).

This property is available since Authlete 2.1.

The JWE enc algorithm for encrypting authorization responses.

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).

This property is available since Authlete 2.1.

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.

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.

Note that this property is used only for the two JWT-based client authentication, namely, PRIVATE_KEY_JWT and CLIENT_SECRET_JWT (see Cient Authentication Method).

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

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

This property is available since Authlete 2.0.

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 "Mutual TLS Profiles for OAuth Clients, 2.3. Dynamic Client Registration" for details.

This property is available since Authlete 2.0.

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 "Mutual TLS Profiles for OAuth Clients, 2.3. Dynamic Client Registration" for details.

This property is available since Authlete 2.1.

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 "Mutual TLS Profiles for OAuth Clients, 2.3. Dynamic Client Registration" for details.

This property is available since Authlete 2.1.

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 "Mutual TLS Profiles for OAuth Clients, 2.3. Dynamic Client Registration" for details.

This property is available since Authlete 2.1.

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 "Mutual TLS Profiles for OAuth Clients, 2.3. Dynamic Client Registration" for details.

This property is available since Authlete 2.1.

The flag to indicate whether this client is required to use the pushed authorization request endpoint.

This property corresponds to the require_pushed_authorization_requests client metadata defined in "OAuth 2.0 Pushed Authorization Requests".

This property is available since Authlete 2.2.

The flag to indicate whether authorization requests from this client are always required to utilize a request object by using either request or request_uri request parameter.

If this flag is set to true and the service's traditionalRequestObjectProcessingApplied is set to false, authorization requests from this client are processed as if require_signed_request_object client metadata of this client is true. The metadata is defined in "JAR (JWT Secured Authorization Request)".

This property is available since Authlete 2.2.

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.

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.

This property is available since Authlete 2.0.

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.

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.

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

An array of URLs each of which points to a request object.

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 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.

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.

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.

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.

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

The flag to indicate whether this client requires auth_time claim to be embedded in the ID token.

This property is set to 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 subject type that the client application requests. Either PUBLIC or PAIRWISE. Details about the subject type are described in OpenID Connect Core 1.0, 8. Subjct Identifier Types.

Note that PAIRWISE is only available since Authlete 2.2.

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

The sector identifier which is a URL starting with https. This URL is used by the service to calculate pairwise subject values. See OpenID Connect Core 1.0, 8.1. Pairwise Identifier Algorithm.

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

This property is depricated since Authlete 2.1.

The value of the sector identifier URI.

This represents the sector_identifier_uri client metadata which is defined in 2. Client Metadata of OpenID Connect Dynamic Client Registration 1.0.

This property is available since Authlete 2.1.

The sector identifier host component as derived from either the sector_identifier_uri or the registered redirect URI. If no sector_identifier_uri is registered and multiple redirect URIs are also registered, the value of this property is null.

This property is available since Authlete 2.2.

The URL pointing to the JWK Set of the client application. The content pointed to by the URL is JSON which complies with the format described in "JSON Web Key (JWK), 5. JSON Web Key Set (JWK Set) Format". 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 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.

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.

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.

This property corresponds to userinfo_encrypted_response_enc 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.

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

The URL pointing to the "Terms Of Service" page.

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 page which describes the policy as to how end-users' profile data are used.

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 home page of the client application.

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 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 "CIBA (Client Initiated Backchannel Authentication)".

This property is depricated since Authlete 2.1.

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 "CIBA (Client Initiated Backchannel Authentication)".

This property is depricated since Authlete 2.1.

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

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

This property is depricated since Authlete 2.1.

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

This property corresponds to the backchannel_user_code_parameter metadata.

This property is depricated since Authlete 2.1.

The attributes of this client.

This property is available since Authlete 2.2.

The extended information about this client. See Client Extension for more details.

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.

This corresponds to urn:openid:params:grant-type:ciba defined in the specification of CIBA (Client Initiated Backchannel Authentication).

This property is available since Authlete 2.1.

This corresponds to urn:ietf:params:oauth:grant-type:device_code defined in the specification of Device Flow.

This property is available since Authlete 2.1.

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.

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.

The description of the scope.

The attributes of the scope.

This property is available since Authlete 2.1.

The sequential number of the service. The value of this property is assigned by Authlete.

The sequential number of the service owner of the service. The value of this property is assigned by Authlete.

The name of the service.

The issuer identifier of the service. A URL that starts with https:// and has no query or fragment component. For example, https://example.com.

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

The description about the service.

The API key. The value of this property is assigned by Authlete.

The API secret. A random 256-bit value encoded by base64url (43 letters). The value of this property is assigned by Authlete.

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

The flag to indicate whether the 'Client ID Alias' feature is enabled or not.

When a new client is created, Authlete generates a numeric value and assigns it as a client ID to the newly created client. In addition to the client ID, each client can have a client ID alias. The client ID alias is, however, recognized only when this property (clientIdAliasEnabled) is true.

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 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 user authentication which is to be prepared on the service side.

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.

API key for Basic authentication at the authentication callback endpoint.

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.

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 as 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.

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.

A Web API endpoint for developer authentication which is to be prepared on the server side.

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.

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.

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.

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 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.

The supported data types that can be used as values of the type field in authorization_details.

This property corresponds to the authorization_data_types_supported metadata. See "OAuth 2.0 Rich Authorization Requests" (RAR) for details.

This property is available since Authlete 2.2.

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

This property is available since Authlete 2.0.

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 authorization endpoint of the service. A URL that starts with https:// and has no fragment component. For example, https://example.com/auth/authorization.

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

The flag to indicate whether the direct authorization endpoint is enabled or not. The path of the endpoint is /api/auth/authorization/direct/service-api-key.

UI locales that the service supports.

Each element is a language tag defined in RFC 5646. For example, en-US and ja-JP.

The value of this property is used as ui_locales_supported 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.

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 S256 is always required as the code challenge method whenever PKCE (RFC 7636) is used.

If this flag is set to true, code_challenge_method=S256 must be included in the authorization request whenever it includes the code_challenge request parameter. Neither omission of the code_challenge_method request parameter nor use of plain (code_challenge_method=plain) is allowed.

This property is available since Authlete 2.1.

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.

This property is available since Authlete 2.1.

The token endpoint of the service. A URL that starts with https:// and has not fragment component. For example, https://example.com/auth/token.

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

The flag to indicate whether the direct token endpoint is enabled or not. The path of the endpoint is /api/auth/token/direct/service-api-key.

Client authentication methods supported by the token endpoint of the service. Valid values are listed in Client Authentication Method. Note that CLIENT_SECRET_JWT and PRIVATE_KEY_JWT are only supported since Authlete 2.0.

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

The flag to indicate token requests from public clients without the client_id request parameter are allowed when the client can be guessed from authorization_code or refresh_token.

This flag should not be set unless you have special reasons.

This property is available since Authlete 2.1.

The revocation endpoint of the service. A URL that starts with https://. For example, https://example.com/auth/revocation.

The flag to indicate whether the direct revocation endpoint is enabled or not. The URL of the endpoint is /api/auth/revocation/direct/service-api-key.

Client authentication methods supported at the revocation endpoint.

This property is available since Authlete 2.0.

The URI of the introspection endpoint.

The flag to indicate whether the direct userinfo endpoint is enabled or not. The path of the endpoint is /api/auth/userinfo/direct/{serviceApiKey}.

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

This property is available since Authlete 2.0.

The URI of the pushed authorization request endpoint.

This property corresponds to the pushed_authorization_request_endpoint metadata defined in " 5. Authorization Server Metadata" of OAuth 2.0 Pushed Authorization Requests.

This property is available since Authlete 2.2.

The duration of pushed authorization requests.

OAuth 2.0 Pushed Authorization Requests defines an endpoint (called "pushed authorization request endpoint") which client applications can register authorization requests into and get corresponding URIs (called "request URIs") from. The issued URIs represent the registered authorization requests. The client applications can use the URIs as the value of the request_uri request parameter in an authorization request.

The property represents the duration of registered authorization requests and is used as the value of the expires_in parameter in responses from the pushed authorization request endpoint.

This property is available since Authlete 2.2.

The flag to indicate whether this service requires that clients use the pushed authorization request endpoint.

This property corresponds to the require_pushed_authorization_requests server metadata defined in OAuth 2.0 Pushed Authorization Requests.

This property is available since Authlete 2.2.

The flag to indicate whether this service requires that authorization requests always utilize a request object by using either request or request_uri request parameter.

If this flag is set to true and the value of traditionalRequestObjectProcessingApplied is false, the value of require_signed_request_object server metadata of this service is reported as true in the discovery document. The metadata is defined in JAR (JWT Secured Authorization Request). That require_signed_request_object is true means that authorization requests which don't conform to the JAR specification are rejected.

This property is available since Authlete 2.2.

The flag to indicate whether a request object is processed based on rules defined in OpenID Connect Core 1.0 or JAR (JWT Secured Authorization Request).

Differences between rules in OpenID Connect Core 1.0 and ones in JAR are as follows.

• JAR requires that a request object be always signed.
• JAR does not allow request parameters outside a request object to be referred to.
• OIDC Core 1.0 requires that response_type request parameter exist outside a request object even if the request object includes the request parameter.
• OIDC Core 1.0 requires that scope request parameter exist outside a request object if the authorization request is an
• OIDC request even if the request object includes the request parameter.

If this flag is set to false and the value of requestObjectRequired is true, the value of require_signed_request_object server metadata of this service is reported as true in the discovery document. The metadata is defined in JAR (JWT Secured Authorization Request). That require_signed_request_object is true means that authorization requests which don't conform to the JAR specification are rejected.

This property is available since Authlete 2.2.

The flag to indicate whether this service validates certificate chains during PKI-based client mutual TLS authentication.

This property is available since Authlete 2.0.

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

This property is available since Authlete 2.0.

The MTLS endpoint aliases.

This property corresponds to the mtls_endpoint_aliases metadata defined in "5. Metadata for Mutual TLS Endpoint Aliases" of OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens.

The aliases will be embedded in the response from the discovery endpoint like the following.

{
     ......,
     "mtls_endpoint_aliases": {
         "token_endpoint":         "https://mtls.example.com/token",
         "revocation_endpoint":    "https://mtls.example.com/revo",
         "introspection_endpoint": "https://mtls.example.com/introspect"
     }
 }

This property is available since Authlete 2.1.

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 flag to indicate whether this service supports issuing TLS client certificate bound access tokens.

This property is available since Authlete 2.0.

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 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 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 of this property is used as the signature algorithm of the JWTs.

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

The key ID to identify a JWK used for signing access tokens.

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 signing from the JWK Set when it generates a JWT-based access token. Authlete Server searches the registered JWK Set for a JWK which satisfies conditions for access 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 property is available since Authlete 2.1.

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 flag to indicate whether the remaining duration of the used refresh token is taken over to the newly issued refresh token.

This property is available since Authlete 2.1.

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.

This property is available since Authlete 2.0.

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.

The flag to indicate whether requests that request no scope are rejected or not.

When a request has no explicit scope parameter and the service's pre-defined default scope set is empty, the authorization server regards the request requests no scope. When this flag is set to true, requests that request no scope are rejected.

The requirement below excerpted from RFC 6749 Section 3.3 does not explicitly mention the case where the default scope set is empty.

However, if you interpret "the default scope set exists but is empty" as "the default scope set does not exist" and want to strictly conform to the requirement above, this flag has to be true.

This property is available since Authlete 2.1.

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

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.

This property is available since Authlete 2.1.

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 locales that the service supports. Each element is a language tag defined in RFC 5646. For example, en-US and ja-JP. 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.

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.

The flag indicating whether claims specified by shortcut scopes (e.g. profile) are included in the issued ID token only when no access token is issued.

To strictly conform to the description below excerpted from OpenID Connect Core 1.0 Section 5.4, this flag has to be true.

This property is available since Authlete 2.1.

The URL of the service's JSON Web Key Set document. For example, http://example.com/auth/jwks.

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 flag to indicate whether the direct jwks endpoint is enabled or not. The path of the endpoint is /api/service/jwks/get/direct/service-api-key.

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 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 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.

This property is available since Authlete 2.1.

The user info endpoint of the service. A URL that starts with https://. For example, https://example.com/auth/userinfo.

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

The flag to indicate whether the direct userinfo endpoint is enabled or not. The path of the endpoint is /api/auth/userinfo/direct/service-api-key.

The boolean flag which indicates whether the OAuth 2.0 Dynamic Client Registration Protocol is supported.

This property is available since Authlete 2.1.

The registration endpoint of the service. A URL that starts with https://. For example, https://example.com/auth/registration.

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

This property is available since Authlete 2.1.

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.

This property is available since Authlete 2.1.

The URL of the "Policy" of the service.

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.

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

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.

The URI of backchannel authentication endpoint, which is defined in the specification of CIBA (Client Initiated Backchannel Authentication).

This property is available since Authlete 2.1.

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).

This property is available since Authlete 2.1.

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.

This property is available since Authlete 2.1.

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.

This property is available since Authlete 2.1.

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.

This property is available since Authlete 2.1.

The flag to indicate whether the binding_message request parameter is always required whenever a backchannel authentication request is judged as a request for Financial-grade API.

The FAPI-CIBA profile requires that the authorization server "shall ensure unique authorization context exists in the authorization request or require a binding_message in the authorization request" (FAPI-CIBA, 5.2.2, 2). The simplest way to fulfill this requirement is to set this property to true.

If this property is set to false, the binding_message request parameter remains optional even in FAPI context, but in exchange, your authorization server must implement a custom mechanism that ensures each backchannel authentication request has unique context.

This property is available since Authlete 2.1.

The URI of the device authorization endpoint.

Device authorization endpoint is defined in the specification of OAuth 2.0 Device Authorization Grant.

This property is available since Authlete 2.1.

The verification URI for the device flow. This URI is used as the value of the verification_uri parameter in responses from the device authorization endpoint.

This property is available since Authlete 2.1.

The verification URI for the device flow with a placeholder for a user code. This URI is used to build the value of the verification_uri_complete parameter in responses from the device authorization endpoint.

It is expected that the URI contains a fixed string USER_CODE somewhere as a placeholder for a user code. For example, like the following.

https://example.com/device?user_code=USER_CODE

The fixed string is replaced with an actual user code when Authlete builds a verification URI with a user code for the verification_uri_complete parameter.

If this URI is not set, the verification_uri_complete parameter won't appear in device authorization responses.

This property is available since Authlete 2.1.

The duration of device verification codes and end-user verification codes issued from the device authorization endpoint in seconds. This is used as the value of the expires_in property in responses from the device authorization endpoint.

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

This property is available since Authlete 2.1.

The character set for end-user verification codes (user_code) for Device Flow.

This property is available since Authlete 2.1.

The length of end-user verification codes (user_code) for Device Flow.

This property is available since Authlete 2.1.

Trust frameworks supported by this service. This corresponds to the trust_frameworks_supported metadata.

This property is available since Authlete 2.2.

Evidence supported by this service. This corresponds to the evidence_supported metadata.

This property is available since Authlete 2.2.

Identity documents supported by this service. This corresponds to the id_documents_supported metadata.

This property is available since Authlete 2.2.

Verification methods supported by this service. This corresponds to the id_documents_verification_methods_supported metadata.

This property is available since Authlete 2.2.

Verified claims supported by this service. This corresponds to the claims_in_verified_claims_supported metadata.

This property is available since Authlete 2.2.

The attributes of this service.

This property is available since Authlete 2.2.

The language tag part.

The value part.

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 target service.

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

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

Start index (inclusive) of the result set of the query.

End index (exclusive) of the result set of the query.

Total number of services owned by the service owner. This doesn't mean the number of services contained in the response.

An array of services.