| Grant Types | Select grant types which this 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.
AUTHORIZATION_CODE is a flow to get issued an authorization code at the authorization endpoint and exchange it with an access token at the token endpoint.
IMPLICIT is a flow to get issued an access token at the authorization endpoint directly.
PASSWORD is a flow to get issued an access token by presenting a user’s credentials (ID & password) at the token endpoint. In normal cases, this flow is used only when other flows cannot be used for some reasons.
CLIENT_CREDENTIALS is a flow to get issued an access token by presenting a client application’s credentials (API key & API secret) at the token endpoint. Access tokens issued by this flow are not associated with any user.
REFRESH_TOKEN is a flow to exchange a refresh token for an access token at the token endpoint. |
| Response Types | Select response types which this 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.
In RFC 6749 (OAuth 2.0), what can be issued at a time at the authorization endpoint is either an authorization code or an access token, but the additional specification of OAuth 2.0 Multiple Response Type Encoding Practices has enabled to issue any combination of an authorization code, an access token and an ID token. Also, an option to issue nothing (NONE) has been created. Select whether to support or not for each combination.
NONE, CODE, TOKEN and ID_TOKEN mean that none, code, token and id_token can be independently specified as a value for response_type parameter of an authorization request, respectively. CODE_TOKEN means that the combination of code token can be specified as a value for response_type parameter. Likewise, CODE_ID_TOKEN is for the combination of code id_token, ID_TOKEN_TOKEN for id_token token, and CODE_ID_TOKEN_TOKEN for code id_token token. |
| Redirect URIs | Redirect URIs that this 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. - The hostname of the redirect URI used for Implicit Grant by a client application whose application type is web must be
localhost. - Based on RFC 8252 OAuth 2.0 for Native Apps, the scheme of the redirect URI for a client application whose application type is native may be either (1) a custom scheme or https, or (2) http, which is allowed only when the hostname is a loopback interface (e.g., 127.0.0.1, [::1]). The use of localhost is permitted but NOT RECOMMENDED.
Requirements by the server implementation:
- Must consist of printable ASCII characters only.
- Must not exceed 200 characters.
Note that the implementation of the authorization server for this client application allows the application type to be unspecified. In other words, client applications do not have to choose web or native as application type. If the application type is not specified, the requirements by OpenID Connect are not checked by the authorization server.
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. |
| Client Authentication Method | The client authentication method that this client application declares that it uses at the token endpoint. This property corresponds to token_endpoint_auth_method in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
NONE corresponds none described in OpenID Connect Core 1.0, 9. Client Authentication. Selecting this implies that this client application does not authenticate at the token endpoint.
CLIENT_SECRET_BASIC corresponds 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. Authorization servers must support this client authentication method.
CLIENT_SECRET_POST corresponds client_secret_post described in OpenID Connect Core 1.0, 9. Client Authentication. In this method, client credentials are embedded in the request body as described in RFC 6749, 2.3. Client Authentication.
CLIENT_SECRET_JWT corresponds client_secret_jwt described in OpenID Connect Core 1.0, 9. Client Authentication.
PRIVATE_KEY_JWT corresponds private_key_jwt described in OpenID Connect Core 1.0, 9. Client Authentication. |
| Assertion Signature Algorithm | The value of alg header parameter of JWS (RFC 7515) which is used for client authentication at the token endpoint.
If none of the algorithms is selected, it means that this client appplication may sign using any algorithm which is supported by the authorization server. On the other hand, if an algorithm is selected, this 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.
This property corresponds to token_endpoint_auth_signing_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata. |
| Request Object Signature Algorithm | The value of alg header parameter of JWS (RFC 7515) that this client application uses for signing a request object.
If none of the algorithms is selected, it means that this client application may use any algorithm supported by the authorization server. On the other hand, if an algorithm is selected, request objects sent from this client application must be signed using the algorithm. Request objects signed by other algorithms are rejected. Note that NONE is different from ‘nothing is selected’.
If an asymmetric signing algorithm is selected, this client application must make available its JWK Set (RFC 7517) which contains a public key for the authorization server to verify the signature of the request object. The URL of the JWK Set has to be set as the value of ‘JSON Web Key Set URI’.
This property corresponds to request_object_signing_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata. |
| Request Object Encryption Algorithm | The value of alg header parameter of JWE (RFC 7516) that this client application uses for encrypting a request object. If an algorithm for Encryption Encoding Algorithm below this is selected, an algorithm for this property has to be selected.
Regardless of whether an algorithm for this property is selected or not, this client application may and may not encrypt a request object. Furthermore, this 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. |
| Request Object Encryption Encoding Algorithm | The value of enc header parameter of JWE (RFC 7516) that this client application uses for encrypting a request object. If an algorithm is selected for Encryption Algorithm above this, the default value of this property is A128CBC_HS256.
This property corresponds to request_object_encryption_enc in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata. |
| Request URIs | URLs each of which points to a request object. Each URL must consist of printable ASCII characters only and its length must not exceed 200.
The implementation of the authorization server for this client application requires that URLs used as values for request_uri request parameter be pre-registered. URLs listed here are regarded as pre-registered. See OpenID Connect Core 1.0, 6.2. Passing a Request Object by Reference for details. |
| Maximum Authentication Age | The default maximum authentication age in seconds. This value is used when an authorization request from this 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. |
| Default ACRs | The default ACRs (Authentication Context Class References). This value is used when an authorization request from this client application has neither acr_values request parameter nor acr claim in claims request parameter.
Each element must consist of printable ASCII characters only and its length must not exceed 200. |
