Authlete has designed and implemented all functions necessary to implement an OAuth 2.0 & OpenID Connect server as Web APIs. On top of the functions to manage metadata of client applications and authorization servers, Authlete also provides functions to implement endpoints such as an authorization endpoint and a token endpoint.

This unique architecture enables developers to use any programming language, including Java, Ruby, PHP and C#. Our OSS libraries and sample implementations will help you build OAuth/OIDC servers within a few days or weeks.

OAuth endpoints, such as authorization endpoint, will be placed in your environment, not ours. Therefore, you can customize UI and UX with no limit. For example, you can separate the authentiation page from authorization page, or you can allow your end-users to choose scopes to be granted.

Authlete can run and manage multiple instances of OAuth 2.0 & OpenID Connect servers simultaneously, which can be managed by consoles.

It is easy to set up new instances: an architect therefore can place multiple authorization servers in a system wherever appropriate without a huge development cost. For example, an architect may have a separate authorization servers for smartphone applications from internal services.

You can integrate Authlete with any IAM solution, authentication solution or API gateway solution of your choice because Authlete focuses on authorization function only. For example, if you have a authentication and IAM systems for your existing service, you can minimize the cost of introducing OAuth and OpenID Connect by integrating Authlete into those systems.

Authlete receives subjects of end-users from your system and associates the subjects with access tokens and other data. Therefore, you don't have to share your end-users credentials with us, which is quite unique compared with other API authorization solutions.

Authlete supports many specifications. Here is the list of the specifications (some specs are only available for ENTERPRISE plan).

Commercially Available

• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage
• RFC 7009: OAuth 2.0 Token Revocation
• RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol
• RFC 7592: OAuth 2.0 Dynamic Client Registration Management Protocol
• RFC 7636: Proof Key for Code Exchange by OAuth Public Clients
• RFC 7662: OAuth 2.0 Token Introspection
• RFC 8628: OAuth 2.0 Device Authorization Grant
• RFC 8705: OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
• RFC 8707: Resource Indicators for OAuth 2.0
• RFC 9101: The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)
• RFC 9126: OAuth 2.0 Pushed Authorization Requests
• RFC 9207: OAuth 2.0 Authorization Server Issuer Identification
• OAuth 2.0 Multiple Response Type Encoding Practices
• OAuth 2.0 Form Post Response Mode
• OAuth 2.0 Rich Authorization Requests
• OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)
• OpenID Connect Core 1.0
• OpenID Connect Discovery 1.0
• OpenID Connect Dynamic Client Registration 1.0
• OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0
• OpenID Connect for Identity Assurance 1.0
• Financial-grade API - Part 1: Read-Only API Security Profile
• Financial-grade API - Part 2: Read and Write API Security Profile
• Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
• Financial-grade API: Client Initiated Backchannel Authentication Profile
• UK Open Banking Security Profile
• Australia Consumer Data Right Security Profile
• Open Banking Brasil Financial-grade API Security Profile

Available Soon

• RFC 8693: OAuth 2.0 Token Exchange
• OpenID Connect Core Error Code unmet_authentication_requirements
• OAuth 2.0 Step-up Authentication Challenge Protocol
• Grant Management for OAuth 2.0
• Transformed Claims
• OpenID Connect Federation 1.0

Responses from Authlete APIs contain a result code and result message.

An example is "[A011308] The host of the redirect URI must be 'localhost' when the client's application type is 'native' and the scheme of the redirect URI is 'http'.", which will help developers solve issues and reduce time to implement OAuth & OpenID Connect using Authlete.

Authlete allows each client to have a client ID alias in addition to the client ID.

This function would be useful when you migrate from the existing authorization server to Authlete and keep using the existing client IDs in the new Authlete system.

Please refer to this document for more details.

Authlete provides a feature that enables an authorization server to associate arbitrary properties with either an access token or authorization code. The authorization server can easily share the properties with resource servers so that they can consume such information for its authorization enforcement as well as making a response.

For example, you would like to develop a money transfer API that can process specific transaction like "send $50 to ABC shop." You could implement such function by creating a "send-50dollar-to-abcshop" scope, but it hardly works as you would have to prepare a lot of scopes that are multiplied with recipients and amounts.

With the properties feature of Authlete, The authorization server can associate the money transfer information (or its handle, if database manages the actual information) with an access token to be issued to a client. The resource server, which hosts the money transfer API, receives an API request with the access token from the client, asks Authlete's introspection API to provide the properties along with details of the token, and then determines if the money transfer request is allowed to proceed.

Please refer to this document for more details.

You can shorten the access token and refresh token duration 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.

Also, you can shorten the access token and refresh token duration per client by configuring from the client developer console.