Skip to main content
For Authlete 2.x documentation, see 2.x version.

​
序文

一般的な推奨事項として、PKCE を使用した認可コードフローを優先的に利用してください。認可コードフローが利用できない場合は、各フローの特性と影響を十分に理解した上で、慎重に代替手段を検討してください。

​
Authlete 管理コンソールにおけるグラントタイプの設定

グラントタイプは Authlete 管理コンソール で設定します。 Authlete は以下のグラントタイプをサポートしています。
  • AUTHORIZATION_CODE
  • IMPLICIT
  • PASSWORD
  • CLIENT_CREDENTIALS
  • REFRESH_TOKEN
  • CIBA
  • DEVICE_CODE
  • TOKEN_EXCHANGE
  • JWT_BEARER
  • PRE_AUTHORIZED_CODE
サービスとクライアントの双方で設定します。サービスで有効にしたグラントタイプが、そのサービスに属するクライアントで選択できるようになります。

​
サービス設定

  1. Authlete 管理コンソール にログインします。
  2. 組織名をクリックし、対象のサービスを選択します。
  3. 「サービス設定 > エンドポイント > 基本設定」の「一般」タブを開きます。
  4. 「サポートするグラントタイプ」で、使用するグラントタイプを選択します。
  5. 「変更を保存」をクリックして設定を適用します。
サービス設定のサポートするグラントタイプ

​
クライアント設定

  1. 対象のクライアントの「クライアント設定」を開きます。
  2. 「エンドポイント > 基本設定」の「一般」タブを開きます。
  3. 「サポート可能な認可タイプ」で、使用するグラントタイプを選択します。
  4. 「変更を保存」をクリックして設定を適用します。
クライアント設定のサポート可能な認可タイプ

​
グラントフローの詳細

RFC 6749 で定義されているグラントタイプは以下の 5 種類です。各グラントタイプでは、クライアントアプリケーションに対して認可エンドポイントやトークンエンドポイントから発行される要素が異なります。

​
認可コードフロー

このフローは最も一般的なグラントフローです。 認可エンドポイントから短命の認可コードを発行することから始まり、その認可コードをトークンエンドポイントでアクセストークンに交換します。これが標準的な OAuth 2.0 のフローです。 クライアントシークレットなどの機密情報を安全に保持できないクライアント（パブリッククライアント、たとえばモバイルアプリ）の場合は、認可コードフローに加えて PKCE (Proof Key for Code Exchange) を使用することが重要です。

​
インプリシットフロー

このフローでは、アクセストークンが認可エンドポイントから直接発行されます。認可コードフローとは異なり、リフレッシュトークンは発行されません。もともとシングルページアプリケーション（SPA）などのトークン要求シナリオ向けに設計されましたが、現在では PKCE を使用した認可コードフローが SPA にも推奨されています。

​
リソースオーナーパスワードクレデンシャルフロー

このフローでは、リソースオーナー（エンドユーザー）の ID とパスワードを受け取り、アクセストークンを発行します。リソースオーナーの認証情報がクライアントアプリケーションに直接渡るため、一般的には避けられます。通常は、OAuth 2.0 を導入する際の移行期間中にのみ使用されます。

​
クライアントクレデンシャルフロー

このグラントフローは、ユーザーが関与しないクライアント向けに定義されています。 クライアントは、クライアント自身の認証情報（クライアント ID とクライアントシークレットの組み合わせ、クライアント証明書、SAML アサーションなど）を使用して、認可サーバーからアクセストークンを取得します。通常、クライアントとリソースオーナーが同じエンティティである場合に使用されます。

​
リフレッシュトークンフロー

このグラントフローは、以前に発行されたアクセストークン（およびリフレッシュトークン）を更新するために定義されています。 クライアントは、以前に取得したリフレッシュトークンを提示して、新しいアクセストークン（および新しいリフレッシュトークン）を認可サーバーから取得します。