OAuth 2.0の認可フレームワーク

Overview

重要なコンセプト

  • Auth0はInternet Engineering Task Force（IETF）によって立案されたOAuth 2.0プロトコルをサポートしている

  • OAuth 2.0仕様のロール、付与タイプ（またはワークフロー）とエンドポイントを理解する

OAuth 2.0の認可フレームワークは、ユーザーがサードパーティのWebサイトにアクセスしたり、アプリケーションがユーザーの保護されたリソースにアクセスしたりする際に、長期有効な資格情報や身元さえ不必要に公開されないようにするプロトコルです。

OAuthは認可レイヤーを導入して、役割をクライアントとリソース所有者で区別しています。OAuthでは、リソースがリソース所有者に管理され、リソースサーバーにホストされている場合​、クライアントがそのリソースに対してアクセスを要求すると、リソース所有者とは異なるセットの資​格情報が発行されます。クライアントは保護されたリソースへのアクセスに、リソース所有者の資格情報を使用するのではな​く、アクセストークンという、特定のスコープ、有効期限、その他のアクセスに関する属性を示す文字列を取得します。アクセストークンは、リソース所有者の承認を得た上で、認可サーバーによってサードパーティのク​ライアントに対して発行されます。そして、クライアントはこのアクセストークンを使って、リソースサーバーがホストしている保護さ​れたリソースにアクセスします。

Auth0は、APIの認可についてアクセストークンをJSON Web Token（JWT）形式で生成します。アクセストークンが示すアクセス権の範囲は、OAuthの用語では、スコープとして知られています。アプリケーションがAuth0で認証する際には、必要なスコープを指定します。スコープがユーザーによって認可されると、アクセストークンに認可されたスコープが含められます。

ロール

OAuth 2.0のフローには以下のロールがあります。

  • Resource Owner（リソース所有者）：保護されたリソースへのアクセスを付与できるエンティティ。大抵の場合、エンドユーザーです。

  • Resource Server（リソースサーバー）：保護されたリソースをホストするサーバー。アクセスしたいAPIのことです。

  • Client （クライアント）：リソース所有者の代わりに保護されたリソースへのアクセス権を要求するアプリケーション。

  • Authorization Server（認可サーバー）：リソース所有者を認証し、適切な認可を得た後にアクセストークンを発行するサーバー。この例では、Auth0です。

付与タイプ

OAuth 2.0はアクセストークンの取得に4つのフローを定義しています。これらのフローは付与タイプと呼ばれています。どのフローが状況に適しているかを決める際に、考慮されるのは主にアプリケーションタイプです。

仕様では、追加の付与タイプを定義する拡張メカニズムも提供されています。付与タイプそれぞれの仕組みと使用するべき状況については、「認証と認可フロー」を参照してください。

エンドポイント

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の実装ではJWT）で、だれがどの許可（スコープ）をどのアプリケーションに対して保持するのかを示します。

使用する付与タイプを認可サーバーに伝えるには、response_type要求パラメーターを以下のように使用します。

  • 認可コード付与の場合にはresponse_type=codeを使用して認可コードを含めます。

  • 暗黙的付与の場合にはresponse_type=tokenを使用してアクセストークンを含めます。別の方法としては、response_type=id_token tokenを使用してアクセストークンとIDトークンの両方を含めます。

IDトークンはJWTで、ログインしたユーザーについての情報が含まれています。OpenID Connect（OIDC）によって導入されました。

OAuth 2.0 Multiple Response Type Encoding Practicesという仕様には、認可要求の結果をどのような形式にするかを指定するパラメーターが追加されています。このパラメーターは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 Found
Location: 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の状態パラメーターを使用する」を参照してください。

もっと詳しく