What distinguishes Authlete is that all functionality required to implement an OAuth 2.0 and OpenID Connect server is designed and implemented as Web APIs. Not only client application registration and authorization server metadata management, but also the logic behind authorization and token endpoints is provided via Web APIs.

As a result, you can use Authlete with any language or framework—Java, Ruby, PHP, C#, and more. Using OSS libraries, you can implement a server in days to weeks.

Authlete delivers OAuth/OIDC behavior through Web APIs. The authorization and token endpoints run in your environment. So you can design the consent UI and user flow to match your product and brand.

With Authlete you can operate multiple OAuth/OIDC server instances.

The management console is built for managing multiple instances. You can add and manage instances with different settings from the console without writing extra code.

You can run separate OAuth/OIDC servers for different use cases—for example, one for mobile apps and one for server-to-server integration, or one for end users and one for admin users—without a large increase in development effort.

Authlete also provides a console to manage client application metadata for each authorization server.

Authlete focuses on authorization and works with any user authentication, identity, or API management solution. You can keep your existing authentication and identity infrastructure and add OAuth/OIDC with minimal development.

When you use Authlete, the only end-user information you need to pass to Authlete is a stable subject identifier per user. Authlete accepts that identifier and associates it with tokens and other protocol data.

You do not need to share end-user names, email addresses, or credentials with Authlete. This is a major difference from all-in-one authentication-and-authorization solutions.

When generating ID tokens, you can send the claims to embed to Authlete’s API to fulfill OpenID Connect behavior.

Authlete supports RFC 6749 and many other specifications. It is OpenID Connect certified and was the first production-ready solution to achieve Financial-grade API (FAPI) certification.

Because OAuth/OIDC behavior is delivered via Web APIs, supporting new specifications places minimal burden on your code. For example, to support PKCE you only need to add the relevant parameters from the client; no change is required in your authorization server implementation.

Below is a subset of the specifications Authlete currently supports (some features are available on Enterprise plans only).

Authlete API responses include result codes and detailed descriptions.

For example: “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’.”

Using these messages helps developers of the authorization server, resource server, and client applications resolve issues faster.

With Authlete’s Client ID Alias feature, each client can have an application-defined client ID in addition to the numeric client ID assigned by Authlete.

This is useful when you already have an authorization server and clients with existing client IDs and want to migrate to Authlete without changing those IDs.

For details, see Using Client ID alias.

Authlete lets you attach arbitrary key-value properties to access tokens or authorization codes. This makes it easier for the authorization server to pass information needed for API authorization or request handling to the resource server.

For example, for a banking API that supports transfers, you could avoid defining a separate scope for every “transfer X yen to payee Y” combination by storing payee and amount as properties on the access token. The API can read those properties from the token and decide whether to allow the transfer.

For details, see How to add extra properties to an access token.

Authlete lets you set shorter access or refresh token lifetimes per client or per scope.

For scope-based duration, use scope attributes: set the attribute key to access_token.duration or refresh_token.duration and the value to the lifetime in seconds. For details, see Token duration per scope.

Per-client settings can be changed in the Developer Console by users with administrator rights, under the “Extended” tab.

Authlete lets you choose whether a refresh token can be reused after it is used to obtain new access tokens.

When “reuse off” is selected, a new refresh token is issued when access tokens are refreshed, and its lifetime is renewed. In this mode, users who call the API regularly within the refresh token lifetime do not need to re-authenticate, while users who stay inactive must re-authenticate when they return.

When “reuse on” is selected, the same refresh token remains valid after use. In this mode, users must re-authenticate when the refresh token expires, regardless of how often they use the API.

For details, see Refresh tokens after being used.

Authlete can require code_challenge_method=S256 for token requests that use PKCE. Requests with code_challenge_method=plain or without code_challenge_method can be rejected.

You can limit to one the number of access tokens issued per user-and-client pair.

For details, see Enabling single access token per subject.

Authlete can store the scopes each user has authorized and expose APIs to list or revoke those authorizations.

This feature is available on Enterprise plans only.

When authenticating clients with tls_client_auth, Authlete can verify the client certificate’s PKI chain.

You can configure the allowed time difference in seconds between server and client clocks.

When a CIBA backchannel authentication request is treated as a FAPI request, Authlete can require that the request include binding_message.