概要
重要なコンセプト
- Auth0はInternet Engineering Task Force（IETF）によって立案されたOAuth 2.0プロトコルをサポートしている
- OAuth 2.0仕様のロール、付与タイプ（またはワークフロー）とエンドポイントを理解する
ロール
OAuth 2.0のフローには以下のロールがあります。- （リソース所有者） ：保護されたリソースへのアクセスを付与できるエンティティ。大抵の場合、エンドユーザーです。
- （リソースサーバー） ：保護されたリソースをホストするサーバー。アクセスしたいAPIのことです。
- Client （クライアント） ：リソース所有者の代わりに保護されたリソースへのアクセス権を要求するアプリケーション。
- （認可サーバー） ：リソース所有者を認証し、適切な認可を得た後にアクセストークンを発行するサーバー。この例では、Auth0です。
付与タイプ
OAuth 2.0はアクセストークンの取得に4つのフローを定義しています。これらのフローは付与タイプと呼ばれています。どのフローが状況に適しているかを決める際に、考慮されるのは主にアプリケーションタイプです。- 認可コードフロー：サーバー上で実行されるWebアプリで使用されます。これは、Proof Key for Code Exchange（PKCE）技術を使用するモバイルアプリでも使用されます。
- フォームPOSTによる暗黙フロー：ユーザーのブラウザー上で実行されるJavaScript中心のアプリ（シングルページアプリケーション）で使用されます。
- リソース所有者のパスワードフロー：高信頼性アプリで使用されます。
- クライアントの資格情報フロー：マシンツーマシンの通信で使用されます。
エンドポイント
OAuth 2.0は、/authorizeエンドポイントおよび/oauth/tokenエンドポイントの2つのエンドポイントを使用します。
認可エンドポイント
/authorizeエンドポイントは、リソース所有者とのやり取りや、保護されたリソースにアクセスするための認可の取得に使用されます。たとえば、Googleアカウントを使ってあるサービスにログインしたいとします。まず、（まだログインしていない場合）認証するために、サービスがGoogleにリダイレクトします。同意の画面が表示され、メールアドレスやコンタクトリストなどのデータ（保護されたリソース）にアクセスすることをサービスに許可するよう求められます。
/authorizeエンドポイントの要求パラメーターは次のとおりです。
| パラメーター | 説明 |
|---|---|
response_type | どの付与を実行するか認可サーバーに指示します。 |
response_mode | （任意）認可要求の結果の形式を指定します。値： - query：認可コード付与の場合です。302 Foundはリダイレクトをトリガーします。- fragment：暗黙付与の場合です。302 Foundはリダイレクトをトリガーします。- form_post：200 OKと、HTMLフォームに隠しパラメーターとして埋め込まれた応答パラメーターが入ります。- web_message：サイレント認証の場合です。HTML5 Webメッセージを使用します。 |
client_id | 認可を求めるアプリケーションのIDです。 |
redirect_uri | URLを含みます。このエンドポイントから正常な応答を受け取ると、このURLにリダイレクトされます。 |
scope | アプリケーションに必要な権限をスペース区切りで列挙します。 |
state | セキュリティ目的で使用される不透明な値です。この要求パラメーターが要求に設定されている場合は、redirect_uriの一部としてアプリケーションに返されます。 |
connection | パスワードレス接続の接続タイプを指定します。 |
/authorizeエンドポイントを最初に呼び出すときに、カスタムクエリパラメーターを構成できます。カスタムクエリパラメーターを使用すると、ユニバーサルログインエクスペリエンスのページテンプレートに追加でコンテキストを提供することができます。
connectionパラメータを使用するには、ID Firstを有効にしてください。connectionパラメーターおよびユニバーサルログインエクスペリエンスに関する詳細については、「ユニバーサルログインのパスワードレス」を参照してください。
ext-のプレフィックスのあるクエリパラメーターは、自動的にページテンプレートのコンテキストに表示されます。
このエンドポイントは認可コードと暗黙の付与タイプに使用されます。発行する証明書の種類に影響するため、認可サーバーはアプリケーションが使いたい付与タイプを知る必要があります。
- 認可コード付与の場合、認可サーバーは認可コードを発行します（その後、それが
/oauth/tokenエンドポイントでアクセストークンと交換できます）。 - 暗黙的付与の場合、認可サーバーはアクセストークンを発行します。このトークンは不透明な文字列（または、Auth0の実装では）で、だれがどの許可（スコープ）をどのアプリケーションに対して保持するのかを示します。
response_type要求パラメーターを以下のように使用します。
- 認可コード付与の場合には
response_type=codeを使用して認可コードを含めます。 - 暗黙的付与の場合には
response_type=tokenを使用してアクセストークンを含めます。別の方法としては、response_type=id_token tokenを使用してアクセストークンとIDトークンの両方を含めます。
response_modeと呼ばれています。任意のパラメーターで、以下の値を指定することができます。
| 値 | 説明 |
|---|---|
query | 認可コード付与のデフォルト値です。成功応答は302 Foundで、redirect_uriへのリダイレクトをトリガーします。応答パラメーターは、Locationヘッダー内にあるredirect_uriのクエリコンポーネント（?に後続の部分）に埋め込まれます。例： HTTP/1.1 302 Found Location: https://my-redirect-uri.callback?code=js89p2x1の場合、認可コードはjs89p21です。 |
fragment | 暗黙付与のデフォルト値です。成功応答は302 Foundで、redirect_uri（要求パラメーター）へのリダイレクトをトリガーします。応答パラメーターは、Locationヘッダー内にあるredirect_uriのフラグメントコンポーネント（#に後続の部分）に埋め込まれます。例： HTTP/1.1 302 FoundLocation: https://my-redirect-uri/callback#access_token=eyB...78f&token_type=Bearer&expires_in=3600 |
form_post | 応答モードは、OAuth 2.0 Form Post Response Mode specificationの仕様に定義されています。成功応答は200 OKで、パラメーターはHTMLフォームに隠されたパラメーターとして埋め込まれます。フォームのactionはredirect_uriで、フォームを送信するためにonload属性が構成されます。ブラウザーがHTMLを読み込むと、redirect_uriにリダイレクトされます。 |
web_message | この応答モードは、OAuth 2.0 Web Message Response Mode specificationの仕様に定義されています。/authorizationエンドポイントからの認可応答でリダイレクトするのではなく、HTML5 Webメッセージングが使用されます。これは、サイレント認証では特に便利です。この応答モードを使用するには、アプリのURLをAuth0のアプリケーション設定にある ［Allowed Web Origins（許可されているWebオリジン）］ フィールドで登録する必要があります。 |
トークンエンドポイント
/oauth/tokenエンドポイントは、アプリケーションがアクセストークンやリフレッシュトークンを取得するのに使用されます。アクセストークンが直接発行される暗黙フローを除いて、すべてのフローで使用されます。
- 認可コードフローでは、アプリケーションは、認可エンドポイントから取得した認可コードをアクセストークンと交換します。
- クライアントの資格情報フローとリソース所有者のパスワード資格情報付与交換では、アプリケーションは資格情報のセットを使って認証し、アクセストークンを取得します。
状態パラメーター
認可プロトコルはstateパラメーターを提供して、アプリケーションを以前の状態に復元できるようにします。stateパラメーターは、クライアントが認可要求で設定した状態オブジェクトの一部を保持して、応答でクライアントが使用できるようにします。状態パラメーターを使用する主な理由は、CSRF攻撃を軽減するためです。詳細については「OAuth 2.0の状態パラメーターを使用する」を参照してください。