全体アーキテクチャ
この図は 4 つの主要な領域で構成されています。Authlete が担う役割
Authlete の内部について、図では 4 つの主要な責務を示しています。プロトコル処理
Authlete は OAuth 2.0 および OpenID Connect のプロトコルロジックを処理します。例えば、認可リクエスト、トークンリクエスト、イントロスペクションリクエスト、取り消し（revocation）リクエストなど、OAuth/OIDC に関連するさまざまな処理を支援します。トークン管理
Authlete は以下のようなトークンを管理します。- 認可コード
- アクセストークン
- リフレッシュトークン
- ID トークン（OpenID Connect を利用する場合）
クライアント管理
Authlete は、以下のような OAuth/OIDC クライアントの情報を管理します。- クライアント ID と認証情報（例: client secret、JWK）
- リダイレクト URI
- 許可するグラントタイプ
- 許可するスコープ
サービス管理
Authlete は、以下のようなサービスレベルの設定も管理します。- Issuer 情報
- サポートする OAuth/OIDC フロー
- サポートするスコープ
- 署名アルゴリズム
- サービスの設定
サービスプロバイダーが引き続き担う役割
Authlete を利用する場合でも、サービスプロバイダーはいくつかの重要なコンポーネントを引き続き運用します。認可サーバー
サービスプロバイダーは、以下のような OAuth/OIDC エンドポイントを保有します。- 認可エンドポイント
- トークンエンドポイント
- 取り消し（revocation）エンドポイント
- イントロスペクションエンドポイント（リソースサーバー向け）
- UserInfo エンドポイント（OpenID Connect のリライングパーティー向け）
- well-known 設定エンドポイント
認証サーバー
サービスプロバイダーはユーザー認証を保有します。 つまり、以下は Authlete の外部にとどまります。- ログイン画面
- ユーザー認証ロジック
- ユーザーデータベース
API サーバー
API サーバーはリソースサーバーを含みます。 クライアントアプリケーションがアクセストークンを付与して API リクエストを送信すると、リソースサーバーはトークンを検証またはイントロスペクションするために Authlete を呼び出す場合があります。典型的なリクエストフロー
図に示した典型的なフローは以下のとおりです。- エンドユーザーが、ブラウザーなどのユーザーエージェントを使用します。
- ユーザーエージェントがクライアントアプリケーションとやり取りします。
- クライアントアプリケーションが、ユーザーエージェント経由で認可リクエストを認可サーバーに送信します。
- 認可サーバーが Authlete を呼び出してリクエストを処理します。
- ユーザーがログインと同意のためにリダイレクトまたは誘導されます。
- 認証サーバーがユーザーデータベースを用いてユーザーを検証します。
- 認可サーバーが認可の判断を行います。
- 認可サーバーが Authlete を呼び出し、認可コードを含む認可レスポンスを生成します。
- 認可サーバーが、ユーザーエージェント経由でクライアントアプリケーションに認可レスポンスを返します。
- クライアントアプリケーションが、トークンエンドポイントで認可コードをアクセストークンと交換するために認可サーバーを呼び出します。
- 認可サーバーが Authlete を呼び出してトークンリクエストを処理します。
- 認可サーバーがクライアントアプリケーションにトークンレスポンスを返します。
- クライアントアプリケーションがそのトークンを用いて API サーバーを呼び出します。
- リソースサーバーが Authlete を呼び出してトークンを検証する場合があります。
- API サーバーがクライアントアプリケーションに応答します。