Documentation Index

Fetch the complete documentation index at: https://developers.authlete.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Overall Architecture

The diagram has four main areas:

---

​

What Authlete Is Responsible For

Inside Authlete, the diagram shows four main responsibilities.

​

Protocol Processing

Authlete handles the OAuth 2.0 and OpenID Connect protocol logic. For example, it helps process authorization requests, token requests, introspection requests, revocation requests, and other OAuth/OIDC-related operations.

​

Token Management

Authlete manages tokens such as:

• Authorization codes
• Access tokens
• Refresh tokens
• ID tokens, in OpenID Connect scenarios

The Authorization Server exposes the endpoint to the client, but Authlete can handle much of the token-related logic behind the scenes.

​

Client Management

Authlete manages OAuth/OIDC client information, such as:

• Client IDs and credentials (e.g., client secrets, JWKs)
• Redirect URIs
• Allowed grant types
• Allowed scopes

​

Service Management

Authlete also manages service-level settings, such as:

• Issuer information
• Supported OAuth/OIDC flows
• Supported scopes
• Signing algorithms
• Service configuration

​

What the Service Provider Still Owns

Even when using Authlete, the Service Provider still runs several important components.

​

Authorization Server

The Service Provider owns the OAuth/OIDC endpoints, such as:

• Authorization endpoint
• Token endpoint
• Revocation endpoint
• Introspection endpoint (for Resource Servers)
• UserInfo endpoint (for OpenID Connect Relying Parties)
• Well-known configuration endpoint

However, these endpoints call Authlete to perform the actual OAuth/OIDC processing.

​

Authentication Server

The Service Provider owns user authentication. That means the following remain outside Authlete:

• Login screens
• User authentication logic
• User database

Authlete does not directly authenticate the user. Instead, it works with the result of authentication performed by the Service Provider.

​

API Server

The API Server contains the Resource Server. When the Client Application sends an API request with an access token, the Resource Server may call Authlete to validate or introspect the token.

​

Typical Request Flow

A typical flow from the diagram is:

1. The End User uses a User Agent, such as a browser.
2. The User Agent interacts with the Client Application.
3. The Client Application sends an authorization request to the Authorization Server via the User Agent.
4. The Authorization Server calls Authlete to process the request.
5. The user is redirected or guided to login and consent.
6. The Authentication Server verifies the user using the User Database.
7. The Authorization Server makes the authorization decision.
8. The Authorization Server calls Authlete to create an authorization response that includes an authorization code.
9. The Authorization Server sends the authorization response back to the Client Application via the User Agent.
10. The Client Application calls the Authorization Server to exchange the authorization code for an access token at the token endpoint.
11. The Authorization Server calls Authlete to process the token request.
12. The Authorization Server sends the token response back to the Client Application.
13. The Client Application uses the token to call the API Server.
14. The Resource Server may call Authlete to validate the token.
15. The API Server responds to the Client Application.