Important Notice：Maintainance Shutdown and Authlete 2.1 Release

We have been providing our authorization services since 2016 at https://api.authlete.com, without any significant system failure. However, to provide better services and help more developers implement OAuth and OIDC related functions, we have decided to temporarily suspend the service between 14:00 and 15:00 UTC on Feb 2nd, 2020, and overhaul the service’s infrastructures.

Along with the overhaul, we will upgrade the Authlete API server from ver 1.1 to 2.1. We will not deprecate any existing APIs, but change the logic of a few APIs slightly. Please check the “Changes in existing APIs” section below.

Changes in existing APIs

1. Strict client authentication checking

• Authlete 2.1 strictly checks the configuration values of the client type and client authentication method. It might refuse some requests that are valid for Authlete 1.1.
• Please check the service and client configurations, referencing to this article.

2. Strict code_verifier checking

• Authlete 2.1 checks whether the value is composed of unreserved characters [A-Z] / [a-z] / [0-9] / “-” / “.” / “_” / “~” from Section 2.3 of [RFC3986], with a minimum length of 43 characters and a maximum length of 128 characters.

Temporary staging environment

• We provide https://stg-api.authlete.com as a temporary test environment.
• You can log in to the server with the same ID/PW and use the same services and client configurations to those at https://stg-api.authlete.com.
• The server will be available until 23:00 Feb 2nd, 2020.

New functionality

New functions listed below will be available according to the update from Authlete 1.1 to Authlete 2.1.

1. Getting and deleting issued access tokens in a batch

• You can get and delete access tokens in a batch using new APIs, /auth/token/get/list and /auth/token/delete. The corresponding refresh tokens will be revoked automatically.
• Please refer to this document for more details.

2. Access/refresh token duration per scope

• You can shorten the access token and refresh token duration, which are configured in the service, per scope using the scope attribute functionality.
• To activate this feature, set up a scope that has a scope attribute with its key of access_token.duration or refresh_token.duration and value of a “shorter” token duration in second. The duration of the tokens with the scope will be the duration set in the scope attribute.
• Please refer to this document for more details.

3. Access/refresh token duration per client

• You can shorten the access token and refresh token duration, which are configured in the service, per client.
• You can configure this setting from the “extension” tab in the client developer console.

4. S256 mandatory for code_challenge_method

• With this update, the authorization server can force its client to use S256 as the value of code_challenge_method and reject requests with code_challenge_method=plain.
• This new functionality is based on OAuth 2.0 Security Best Current Practice.
• You can configure this setting from the “Authorization” tab in the service owner console.

5. New client authentication methods

• We will add 4 new client methods, client_secret_jwt, private_key_jwt, tls_client_auth, andself_signed_tls_client_auth according to RFC7523 and MTLS .
• Please refer to the following documents for more details.
  • OAuth 2.0 Client Authentication
  • client_secret_jwt in the Knowledge base
  • private_key_jwt in the Knowledge Base
  • tls_client_auth in the Knowledge base

6. JWT-based access token

• You can issue a JWT-based access token.
• Please refer to this document for details.

7. JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)

• You can use query.jwt, fragment.jwt, form_post.jwt, and jwt as a parameter of response_mode, which are defined in Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM).
• This feature will enhance the security of the authorization response by adding support for signing and encryption, sender authentication, audience restriction and protection from replay, credential leakage, and mix-up attacks.

8. Dynamic Client Registration support

• We offer new APIs, /client/registration, that supports RFC7591 and RFC7592.
• We recommend using the original client management APIs, /client/*. Please try the new ones when you have to support the specifications.

9. Device Flow support

• You can implement Device Flow defined in RFC8628.
• This feature enables OAuth clients on devices, such as smart TVs, media consoles, digital picture frames, and printers, to obtain user authorization to access protected resources by using a user agent on a separate device.

10. CIBA Flow support

• You can implement CIBA Flow defined in OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0.
• Please refer to this article for more details.

11. Financial-grade API support

• You can implement Financial-grade API, Open Banking, and FAPI-CIBA.
• Please refer to this article for more details.
• This feature is optional. Please contact us for pricing.

References

• Knowledge Base
• API Document
• Spec Sheet
• API Tutorials