Introduction

Developer Console is a Web console for developers to manage their client applications.

It is not explicitly written in any specification, but you have to provide third-party developers (and yourself) with a Web console for them to manage their client applications. It is a time-consuming task to develop such a tool, but you are free from the task. Authlete offers Developer Console and you can let your third-party developers use it.

To let third-party developers login Developer Console, you are required to implement a developer authentication callback endpoint. On the other hand, if you are the only developer for your service, you don’t have to implement the endpoint. Read “Developer Authentication Callback” for details.

Anyway, this document describes how to use Developer Console.

Login

Developer Console for a service is provided at the URL below.

https://cd.authlete.com/SERVICE_API_KEY/

The login form accepts a pair of ID & password of a developer. It is different from the ID & password of your Authlete account.

Authlete delegates developer authentication to your developer authentication callback endpoint, so any developer cannot login Developer Console until you implement the endpoint for the service.

However, as a special behavior, the login form accepts the pair of API key & API secret of the corresponding service as if it were a valid pair of ID & password of a developer. Therefore, if you are the only person who manages client applications for your service, you don’t have to implement a developer authentication callback endpoint.

Anyway, you (the service owner of the service) can login Developer Console with the API key and the API secret of the service without implementing a developer authentication callback endpoint.

It is only when you want to let other developers use Developer Console that you are required to implement a developer authentication callback. Read “Developer Authentication Callback” for details.

List Apps

To list client applications, do either of the following.

• Open “Menu” on the left and select “Your Apps”.
• Access the URL below directly. https://cd.authlete.com/service-api-key/clients/list

Right after registration, your first service has one client application, so if you login Developer Console with the API key and the API secret of the service, the list will appear like the following.

By clicking the client name, you can display App Details page of the client application. In the figure, “Client 5008706718” is the client name.

“Edit” button on the right is a button to start editing configuration parameters of the client application. See “Edit App” for details.

“Delete” button is a button to delete the client application. See “Delete App” for details.

Create App

It is very easy to create a new client application using Developer Console. To start creating a new client application, do one of the following.

• Open “Menu” on the left and select “Create App”.
• Click “Create App” button in the app list page.
• Access the URL below directly. https://cd.authlete.com/service-api-key/clients/new

As the number of configuration parameters of a client application is not small, they are categorized. In Create App page, there are tabs for each category.

Change the values of the configuration parameters as you like, or leave all of them untouched to use their default values. See Edit App for details about the configuration parameters.

After editing, click “Create” button at the bottom of Create App page to create a new service.

That’s all.

Edit App

1. Start Editing

To start editing configuration parameters of a client application, do either of the following.

• Click “Edit” button in Your Apps page or App Details page.
• Access the URL below directly. Don’t forget to replace service-api-key and client-id. https://cd.authlete.com/service-api-key/clients/client-id/edit

2. Configuration Categories

As the number of configuration parameters of a client application is not small, they are categorized. In Edit App page, there are tabs for the categories.

Category	Description
Basic	Basic information such as client name, client ID and client secret.
Authorization	Settings related to authorization such as redirect URIs.
ID Token	Settings related to ID token such as signature algorithm.
JWK Set	Settings related to JSON Web Key Set (RFC 7517).
OIDC Endpoint	Settings related to OpenID Connect endpoints such as user info endpoint.
Document	URLs of documents of the client application.

3. Configuration: Basic

Setting Item	Description
Client Name	The name of this client application. 100 characters at most. This property corresponds to client_name in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Description	The description about this client application. 200 characters at most.
Client ID	The client ID assigned by the authorization server to this client application. This corresponds to client_id in RFC 6749.
Client Secret	The client secret issued by the implementation of the authorization server to this client application. A random 512-bit value encoded by base64url (86 characters). This property corresponds to client_secret in RFC 6749. Note that the authorization server 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 the authorization server should not come along with a client secret although RFC 6749, 3.2.1. Client Authentication says as follows: Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint.
Client Type	The client type of this client application. Either CONFIDENTIAL or PUBLIC. See [RFC 6749, 2.1. Client Types][6749_21] for details.
Application Type	The application type of this client application. WEB, NATIVE, or unspecified. The value of this property affects the validation steps for a redirect URI. See the help of Redirect URIs for details. This property corresponds to application_type in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Logo URI	The URL pointing to the logo image of this client application. The URL must consist of printable ASCII characters only and its length must not exceed 200. This property corresponds to logo_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Contacts	Email addresses of people responsible for this client application. Each email address must consist of printable ASCII characters only and its length must not exceed 100. The maximum number of email addresses is 255. This property corresponds to contacts in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

4. Configuration: Authorization

Setting Item	Description
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. 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. 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.

5. Configuration: ID Token

Setting Item	Description
Signature Algorithm	The value of alg header parameter of JWS (RFC 7515) that this client application requires the authorization server to use for signing an ID token. The default value is RS256. NONE may be specified, but in that case, this client application cannot obtain an ID token from the authorization server. 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.
Encryption Algorithm	The value of alg header parameter of JWE (RFC 7516) that this client application requires the authorization server to use for encrypting an ID token. If no algorithm is selected, it means that ID tokens are not encrypted. When an algorithm is selected for Encryption Encoding Algorithm below this, an algorithm for this property must be selected. If the value of this property indicates an asymmetric encryption algorithm, this client application must make its JWK Set (RFC 7517) available at the URL pointed to by JWK Set URI (see ‘JWK Set’ tab). The JWK Set must contain a public key for the authorization server to use for encrypting ID tokens. This property corresponds to id_token_encrypted_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Encryption Encoding Algorithm	The value of enc header parameter of JWE (RFC 7516) that this client application requires the authorization server to use for encrypting an ID token. If an algorithm is selected for Encryption Algorithm above this, the default value of this property is A128CBC_HS256. This property corresponds to id_token_encrypted_response_enc in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Authentication Time Required	Select YES if this client application always requires the auth_time claim to be in ID tokens. This property corresponds to require_auth_time in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Subject Type	The subject type that this client application requests. See OpenID Connect Core 1.0, 8. Subjct Identifier Types for details. This property corresponds to subject_type in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata. Note that, however, the implementation of the authorization server for this client application does not support PAIRWISE, so it behaves the same way as PUBLIC even if PAIRWISE is set to this property.
Sector Identifier	The sector identifier which is a URL starting with https. The URL must consist of printable ASCII characters only and its length must not exceed 200. This URL is used by the authorization server to calculate pairwise subject values. See OpenID Connect Core 1.0, 8.1. Pairwise Identifier Algorithm for details. This property corresponds to sector_identifier_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata. Note that, however, the implementation of the authorization server for this client application does not support pairwise subject values, so it does not refer to the value of this property.

6. Configuration: JWK Set

Setting Item	Description
JWK Set URI	The URL pointing to the JWK Set (JSON Web Key Set) of this client application. The URL must consist of printable ASCII characters only and its length must not exceed 200. The content of the resource pointed to by the URL must be JSON which complies with the format described in RFC 7517, 5. JWK Set Format. Of course, the JWK Set must not include private keys of this client application. If this client application requests encryption for ID tokens (from the authorization/token/userinfo endpoints) and/or signs/encrypts request objects, it must make available its JWK Set containing public keys for decryption and/or verification. The value of this property is the URL at which the JWK Set is available. The authorization server fetches the JWK Set from the URL. OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata says that jwks (JWK Set Content) must not be used when the client can use jwks_uri (JWK Set URI), but the authorization server for this client application allows both properties to be registered at the same time and just does not use jwks when jwks_uri is registered. This property corresponds to jwks_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
JWK Set Content	The content of the JWK Set (JSON Web Key Set) of this client application. The format is described in RFC 7517, 5. JWK Set Format. Of course, the JWK Set must not include private keys of this client application. OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata says that jwks (JWK Set Content) must not be used when the client can use jwks_uri (JWK Set URI), but the authorization server for this client application allows both properties to be registered at the same time and just does not use jwks when jwks_uri is registered. This property corresponds to jwks in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

7. Configuration: OIDC Endpoint

Setting Item	Description
User Info Endpoint Signature Algorithm	The value of alg header parameter of JWS (RFC 7515) that this client application requires the authorization server to use for signing the JWT (RFC 7519) returned from the user info endpoint. When no algorithm is selected, data from the user info endpoint is not signed. If both Signature Algorithm and Encryption Algorithm are not specified, the format of the response from the user info endpoint is a plain JSON (not JWT). Note that ’not specified’ and NONE have different meanings for this property. This property corresponds to userinfo_signed_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
User Info Endpoint Encryption Algorithm	The value of alg header parameter of JWE (RFC 7516) that this client application requires the authorization server to use for encrypting the JWT (RFC 7519) returned from the user info endpoint. When no algorithm is selected, data from the user info endpoint is not encrypted. If an algorithm is selected for Encryption Encoding Algorithm below this, an algorithm for this property must be selected. If the value of this property indicates an asymmetric encryption algorithm, this client application must make its JWK Set (RFC 7517) available at the URL pointed to by JWK Set URI (see ‘JWK Set’ tab). The JWK Set must contain a public key for the authorization server to use for encrypting data from the user info endpoint. If both Signature Algorithm and Encryption Algorithm are not specified, 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.
User Info Endpoint Encryption Encoding Algorithm	The value of enc header parameter of JWE (RFC 7516) that this client application requires the authorization server to use for encrypting the JWT (RFC 7519) returned from the user info endpoint. When an algorithm is selected for Encryption Algorithm, the default value of this property is A128CBC_HS256. This property corresponds to userinfo_encrypted_response_enc in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Login Endpoint URI	The URL which a third-party program can use to initiate a login by this client application. The URL must start with https and consist of ASCII characters only. Its length must not exceed 200. This property corresponds to initiate_login_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

8. Configuration: Document

Setting Item	Description
Terms of Service URI	The URL pointing to the Terms Of Service page. The URL must consist of printable ASCII characters only and its length must not exceed 200. This property corresponds to tos_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Client Data Policy URI	The URL pointing to the page which describes the policy as to how end-users’ profile data are used. The URL must consist of printable ASCII characters only and its length must not exceed 200. This property corresponds to policy_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Home Page URI	The URL pointing to the home page of this client application. The URL must consist of printable ASCII characters only and its length must not exceed 200. This property corresponds to client_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.

9. Apply Changes

After editing configuration parameters, click “Update” button at the bottom of Edit App page to apply the changes.

Delete App

To delete a client application, click “Delete” button in Your Apps page or App Details page.

A confirmation dialog is displayed. Initially, “Delete” button in the dialog is disabled. Input the name of the client application in the text field in the dialog, and “Delete” button is enabled.

Click “Delete” button in the dialog, and the client application is deleted.