> ## 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.
# アーキテクチャ
> Authlete は OAuth 2.0 および OpenID Connect の処理を担うバックエンドエンジンとして動作します。エンドユーザーやクライアントアプリケーションから直接アクセスされることはなく、サービスプロバイダー自身のシステム、主に認可サーバーと API サーバーから呼び出されます。
## 全体アーキテクチャ
```mermaid placement="top-right" theme={null}
%%{init: {
'themeVariables': {
'fontSize': '24px',
'nodeTextMargin': 40
},
'flowchart': {
'nodeSpacing': 40,
'rankSpacing': 40,
'padding': 5
}
}}%%
graph LR
subgraph user[End User]
direction TB
ro[Resource
Owner]
ua[User
Agent]
ro --> ua
end
subgraph app[Client Application]
direction TB
client[OAuth Client /
OIDC RP]
end
subgraph provider[Service Provider]
direction TB
subgraph auth[Authentication Server]
direction TB
user_authn[User
Authentication]
user_db[User
Database]
user_authn --> user_db
end
subgraph as[Authorization Server]
direction TB
oauth_ep[OAuth/OIDC
Endpoints]
authz_decision[Authorization
Decision]
end
subgraph api[API Server]
direction TB
rs[Resource
Server]
end
end
subgraph authlete[Authlete]
direction TB
protocol_processing[Protocol
Processing]
token_management[Token
Management]
client_management[Client
Management]
service_management[Service
Management]
end
%% User interaction with client
ua --> client
%% User authentication / consent
ua -- Login / Consent --> user_authn
%% Authorization request via User Agent
ua -- Authorization Request --> oauth_ep
%% Direct client-to-AS communication
client -- Token
Request --> oauth_ep
%% Authorization server internal processing
oauth_ep --> authz_decision
oauth_ep --> authlete
%% API access
client -- API
Request --> rs
rs --> authlete
```
この図は 4 つの主要な領域で構成されています。
| 領域 | 役割 |
| -------------- | --------------------------------------------------------- |
| エンドユーザー | 実際の利用者と、そのブラウザーまたはユーザーエージェント |
| クライアントアプリケーション | OAuth クライアント / OIDC リライングパーティー（例: Web アプリやモバイルアプリ） |
| サービスプロバイダー | 認可サーバー、認証サーバー、API サーバーを管理するシステム |
| Authlete | OAuth/OIDC のプロトコルロジック、トークン管理、クライアント管理、サービス管理を担うバックエンドサービス |
***
## Authlete が担う役割
Authlete の内部について、図では 4 つの主要な責務を示しています。
### プロトコル処理
Authlete は OAuth 2.0 および OpenID Connect のプロトコルロジックを処理します。例えば、認可リクエスト、トークンリクエスト、イントロスペクションリクエスト、取り消し（revocation）リクエストなど、OAuth/OIDC に関連するさまざまな処理を支援します。
### トークン管理
Authlete は以下のようなトークンを管理します。
* 認可コード
* アクセストークン
* リフレッシュトークン
* ID トークン（OpenID Connect を利用する場合）
エンドポイントをクライアントに公開するのは認可サーバーですが、トークンに関連するロジックの多くは Authlete が背後で処理できます。
### クライアント管理
Authlete は、以下のような OAuth/OIDC クライアントの情報を管理します。
* クライアント ID と認証情報（例: client secret、JWK）
* リダイレクト URI
* 許可するグラントタイプ
* 許可するスコープ
### サービス管理
Authlete は、以下のようなサービスレベルの設定も管理します。
* Issuer 情報
* サポートする OAuth/OIDC フロー
* サポートするスコープ
* 署名アルゴリズム
* サービスの設定
## サービスプロバイダーが引き続き担う役割
Authlete を利用する場合でも、サービスプロバイダーはいくつかの重要なコンポーネントを引き続き運用します。
### 認可サーバー
サービスプロバイダーは、以下のような OAuth/OIDC エンドポイントを保有します。
* 認可エンドポイント
* トークンエンドポイント
* 取り消し（revocation）エンドポイント
* イントロスペクションエンドポイント（リソースサーバー向け）
* UserInfo エンドポイント（OpenID Connect のリライングパーティー向け）
* well-known 設定エンドポイント
ただし、これらのエンドポイントは実際の OAuth/OIDC 処理を行うために Authlete を呼び出します。
### 認証サーバー
サービスプロバイダーはユーザー認証を保有します。
つまり、以下は Authlete の外部にとどまります。
* ログイン画面
* ユーザー認証ロジック
* ユーザーデータベース
Authlete がユーザーを直接認証することはありません。代わりに、サービスプロバイダーが実施した認証の結果と連携して動作します。
### API サーバー
API サーバーはリソースサーバーを含みます。
クライアントアプリケーションがアクセストークンを付与して API リクエストを送信すると、リソースサーバーはトークンを検証またはイントロスペクションするために Authlete を呼び出す場合があります。
## 典型的なリクエストフロー
図に示した典型的なフローは以下のとおりです。
1. エンドユーザーが、ブラウザーなどのユーザーエージェントを使用します。
2. ユーザーエージェントがクライアントアプリケーションとやり取りします。
3. クライアントアプリケーションが、ユーザーエージェント経由で認可リクエストを認可サーバーに送信します。
4. **認可サーバーが Authlete を呼び出してリクエストを処理します。**
5. ユーザーがログインと同意のためにリダイレクトまたは誘導されます。
6. 認証サーバーがユーザーデータベースを用いてユーザーを検証します。
7. 認可サーバーが認可の判断を行います。
8. **認可サーバーが Authlete を呼び出し、認可コードを含む認可レスポンスを生成します。**
9. 認可サーバーが、ユーザーエージェント経由でクライアントアプリケーションに認可レスポンスを返します。
10. クライアントアプリケーションが、トークンエンドポイントで認可コードをアクセストークンと交換するために認可サーバーを呼び出します。
11. **認可サーバーが Authlete を呼び出してトークンリクエストを処理します。**
12. 認可サーバーがクライアントアプリケーションにトークンレスポンスを返します。
13. クライアントアプリケーションがそのトークンを用いて API サーバーを呼び出します。
14. **リソースサーバーが Authlete を呼び出してトークンを検証する場合があります。**
15. API サーバーがクライアントアプリケーションに応答します。
```mermaid placement="top-right" theme={null}
sequenceDiagram
box End User
participant EndUser as End User
participant UserAgent as User Agent
end
box Client Application
participant ClientApp as Client
Application
end
box Service Provider
participant AuthzServer as Authorization
Server
participant UserAuthn as Authentication
Server
participant APIServer as Resource
Server
end
box Authlete
participant Authlete as Authlete
end
EndUser->>UserAgent: Use browser
UserAgent->>ClientApp: Interact with app
ClientApp-->>UserAgent: Authorization request
UserAgent->>AuthzServer: Authorization request
AuthzServer->>Authlete: Send authorization request content
Authlete-->>AuthzServer: "ticket" and other data (e.g., client info, requested scopes, etc.)
AuthzServer->>UserAuthn: Process user
authentication
UserAuthn<<->>UserAgent: Verify user
UserAuthn->>UserAuthn: Verify user credentials
UserAuthn-->>AuthzServer: Authentication
result
AuthzServer->>AuthzServer: Make authorization decision
AuthzServer->>Authlete: Send "ticket" and other data (e.g., subject identifier, claims, etc.)
Authlete-->>AuthzServer: Authorization response data
AuthzServer-->>UserAgent: Send authorization response
UserAgent->>ClientApp: Send authorization
response
ClientApp->>AuthzServer: Token request
AuthzServer->>Authlete: Send token request content
Authlete-->>AuthzServer: Token response data
AuthzServer-->>ClientApp: Send token response
ClientApp->>APIServer: API request with token
APIServer->>Authlete: Token introspection
(optional)
Authlete-->>APIServer: Token introspection
result (optional)
APIServer-->>ClientApp: API response
```