Table of Contents
一般的な推奨事項として、PKCE を使用した認可コードフローを優先的に利用してください。認可コードフローが利用できない場合は、各フローの特性と影響を十分に理解した上で、慎重に代替手段を検討してください。
Authlete Management Console でグラントタイプを設定できます。
Authlete は以下のグラントタイプをサポートしています：
AUTHORIZATION_CODEIMPLICITPASSWORDCLIENT_CREDENTIALSREFRESH_TOKENCIBADEVICE_CODETOKEN_EXCHANGEJWT_BEARERPRE_AUTHORIZED_CODEAuthlete では、サービス設定でグラントタイプを設定できます。
Authlete では、クライアント設定でグラントタイプを設定できます。
RFC6749 で定義されているグラントタイプは以下の 5 種類です。各グラントタイプでは、クライアントアプリケーションに対して認可エンドポイントやトークンエンドポイントから発行される要素が異なります。
| フロー | 認可エンドポイント | トークンエンドポイント |
|---|---|---|
| 認可コードフロー | 認可コード | アクセストークン、リフレッシュトークン |
| インプリシットフロー | アクセストークン | - |
| リソースオーナーパスワードクレデンシャルフロー | - | アクセストークン、リフレッシュトークン |
| クライアントクレデンシャルフロー | - | アクセストークン |
| リフレッシュトークンフロー | - | アクセストークン、リフレッシュトークン |
このフローは最も一般的なグラントフローです。
このフローは、認可エンドポイントから短命の認可コードを発行することから始まります。その後、認可コードをトークンエンドポイントでアクセストークンに交換します。これは標準的な OAuth 2.0 のフローです。
クライアント（例：公開クライアント）がクライアントシークレットなどの機密情報を安全に保存できない場合（例：モバイルアプリ）、認可コードフローに加えて PKCE (Proof Key for Code Exchange) を使用することが重要です。
このフローでは、アクセストークンが認可エンドポイントから直接発行されます。認可コードフローとは異なり、リフレッシュトークンは発行されません。このフローは、もともとシングルページアプリケーション（SPA）などのトークン要求シナリオ向けに設計されましたが、現在では PKCE を使用した認可コードフローが SPA に推奨されています。
このフローでは、リソースオーナー（エンドユーザー）の ID とパスワードを受け取り、アクセストークンを発行します。しかし、リソースオーナーの資格情報がクライアントアプリケーションに直接露出するため、一般的には避けられます。このフローは通常、OAuth 2.0 を導入する際の移行期間中にのみ使用されます。
このグラントフローは、ユーザーが関与しないクライアント向けに定義されています。
クライアントは、クライアント自身の認証情報（例：クライアント ID とクライアントシークレットの組み合わせ、クライアント証明書、SAML アサーション）を使用して、認可サーバーからアクセストークンを取得します。
このフローでは、クライアント認証のみに基づいてアクセストークンが発行されます。通常、クライアントとリソースオーナーが同じエンティティである場合に使用されます。
このフローは、リフレッシュトークンを提示し、新しいアクセストークンを発行するためのものです。
このグラントフローは、以前に発行されたアクセストークン（およびリフレッシュトークン）を更新するために定義されています。
クライアントは、以前に取得したリフレッシュトークンを使用して、新しいアクセストークン（および新しいリフレッシュトークン）を認可サーバーから取得します。