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 indicating whether Authlete generates access tokens for external attachments and embeds them in ID tokens and userinfo responses.

The signature algorithm of access tokens.

Symmetric algorithms (JWSAlg.HS256, JWSAlg.HS384 and JWSAlg.HS512) cannot be used for this property. When this property is not set, access tokens issued by this service are just random strings. On the other hand, when it 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 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 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 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 API key. The value of this property is assigned by Authlete. Even if the property has a value in a request to Authlete /service/create API or /service/update API, 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 request to Authlete /service/create API or /service/update API, it is ignored.

Arbitrary attributes associated with this service.

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.

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.

See 'Authentication Callback' for details.

The authorization endpoint of the service. A URL that starts with https:// and has no fragment component (e.g. https://example.com/auth/authorization).

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

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 URI of the backchannel authentication endpoint.

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

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 boolean flag which indicates 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 true to this property.

If false is set to this property, 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.

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 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 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 set to true.

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

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

The flag indicating whether the scope request parameter in dynamic client registration/update requests is used as requestable scopes.

The description about the service.

API key for Basic authentication at the developer authentication callback endpoint.

If the property is set, 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.

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.

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

The URI of the device authorization endpoint.

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

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. Must be in between 0 and 65,535.

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.

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.

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 path of the endpoint is /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 Web APIs such as /auth/authorization, /auth/authorization/issue and /auth/authorization/fail.

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

If true, the default implementation of the userinfo endpoint of this service works. The path of the endpoint is /auth/introspection/direct/{serviceApiKey}.

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 /auth/introspection API or /auth/introspection/standard 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 path of the endpoint is /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 /service/jwks/get API.

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 path of the endpoint is /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 /auth/revocation API.

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 path of the endpoint is /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 Web APIs such as /auth/token, /auth/token/issue and /auth/token/fail.

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 path of the endpoint is /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 /auth/userinfo API.

The boolean to indicate whether the dynamic client registration is supported.

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 flag indicating whether encryption of request object is required when the request object is passed through the front channel.

The flag indicating whether every authorization request must include the grant_management_action request parameter.

The URL of the grant management endpoint.

Hardware-secured keys. Output only.

The flag indicating whether HSM (Hardware Security Module) support is enabled for this service.

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

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 URI of the introspection endpoint.

The flag indicating whether generation of the iss response parameter is suppressed.

The issuer identifier of the service. A URL that starts with https:// and has no query or fragment component (e.g. 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 content of the service's JSON Web Key Set document.

If this property is set in a request to Authlete /service/create API or /service/update API, Authlete hosts the content in the database.

See OpenID Connect Core 1.0, 10. Signatures and Encryption for details.

The URL of the service's JSON Web Key Set document (e.g. 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 indicating whether the port number component of redirection URIs can be variable when the host component indicates loopback.

The metadata of the service. The content of the returned array depends on contexts.

The flag indicating whether 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.

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

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"
    }
}

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

The flag indicating whether the nbf claim in the request object is optional even when the authorization request is regarded as a FAPI-Part2 request.

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

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

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 which indicates whether S256 is always required as the code challenge method whenever PKCE is used.

If true is set, 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.

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.

Predefined transformed claims in JSON format. Available from Authlete 2.3 onwards.

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 value of this 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.

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.

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 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 registration endpoint of the service. A URL that starts with https:// (e.g. https://example.com/auth/registration).

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.

The flag indicating whether Authlete checks whether the aud claim of request objects matches the issuer identifier of this service.

The flag indicating whether the JWE alg of encrypted request object must match the value of the request_object_encryption_alg client metadata.

The flag indicating whether the JWE enc of encrypted request object must match the value of the request_object_encryption_enc client metadata.

The flag indicating whether authorization requests must utilize a request object.

The revocation endpoint of the service. A URL that starts with https:// (e.g. https://example.com/auth/revocation).

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

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 name of the service.

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 request to Authlete /service/create API or /service/update API, it is ignored.

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]( https://tools.ietf.org/html/rfc6749#section-4.4) 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 property is set to true or false.

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.

Supported attachment types. This property corresponds to the attachments_supported server metadata which was added by the third implementer's draft of OpenID Connect for Identity Assurance 1.0.

Supported authorization details types for "authorization_details".

This property was renamed from supportedAuthorizationDataTypes to align with the change made by the 5th draft of the RAR specification.

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

Claim locales that the service supports. Each element is a language tag defined in RFC 5646 (e.g. '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 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.

Claim types supported by the service.

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

Custom client metadata supported by this service.

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 /developer/sns/redirection as the redirection endpoint of the client application.

Supported algorithms used to compute digest values of external attachments. This property corresponds to the digest_algorithms_supported server metadata which was added by the third implementer's draft of OpenID Connect for Identity Assurance 1.0.

Values of display request parameter that service supports.

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

Supported documents. This property corresponds to the documents_supported server metadata which was renamed to from id_documents_supported by the third implementer's draft of OpenID Connect for Identity Assurance 1.0.

Supported validation and verification processes. This property corresponds to the documents_methods_supported server metadata which was renamed to from id_documents_verification_methods_supported by the third implementer's draft of OpenID Connect for Identity Assurance 1.0.

Supported document validation methods. This property corresponds to the documents_validation_methods_supported server metadata which was added by the third implementer's draft of OpenID Connect for Identity Assurance 1.0.

Supported document verification methods. This property corresponds to the documents_verification_methods_supported server metadata which was added by the third implementer's draft of OpenID Connect for Identity Assurance 1.0.

Supported electronic record types. This property corresponds to the electronic_records_supported server metadata which was added by the third implementer's draft of OpenID Connect for Identity Assurance 1.0.

Evidence supported by this service.

This corresponds to the evidence_supported metadata.

Values of grant_type request parameter that the service supports.

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

Client authentication methods supported at the introspection endpoint.

Values of response_type request parameter that the service supports.

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

Client authentication methods supported at the revocation endpoint.

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 profiles that this service supports.

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 /sns/redirection as the redirection endpoint of the client application.

Client authentication methods supported by the token endpoint of the service.

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

Trust frameworks supported by this service.

This corresponds to the trust_frameworks_supported metadata.

UI locales that the service supports. Each element is a language tag defined in RFC 5646 (e.g. 'en-US' and 'ja-JP').

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

Verified claims supported by this service.

This corresponds to the claims_in_verified_claims_supported metadata.

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

The token endpoint of the service. A URL that starts with https:// and has not fragment component (e.g. https://example.com/auth/token).

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

The flag indicating whether to prohibit public clients from making token exchange requests.

The flag indicating whether to prohibit unidentifiable clients from making token exchange requests.

The flag indicating whether to prohibit clients that have no explicit permission from making token exchange requests.

The flag indicating whether the expiration date of an access token never exceeds that of the corresponding refresh token.

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

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

The flag indicating whether to let /client/registration API use ClientRegistrationResponse.Action.UNAUTHORIZED whenever appropriate.

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

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

The user info endpoint of the service. A URL that starts with https:// (e.g. https://example.com/auth/userinfo).

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

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.