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つのフローを定義しています。これらのフローは付与タイプと呼ばれています。どのフローが状況に適しているかを決める際に、考慮されるのは主にアプリケーションタイプです。

• 認可コードフロー：サーバー上で実行されるWebアプリで使用されます。これは、Proof Key for Code Exchange（PKCE）技術を使用するモバイルアプリでも使用されます。
• フォームPOSTによる暗黙フロー：ユーザーのブラウザー上で実行されるJavaScript中心のアプリ（シングルページアプリケーション）で使用されます。
• リソース所有者のパスワードフロー：高信頼性アプリで使用されます。
• クライアントの資格情報フロー：マシンツーマシンの通信で使用されます。

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

​

エンドポイント

OAuth 2.0は、/authorizeエンドポイントおよび/oauth/tokenエンドポイントの2つのエンドポイントを使用します。

​

認可エンドポイント

/authorizeエンドポイントは、リソース所有者とのやり取りや、保護されたリソースにアクセスするための認可の取得に使用されます。たとえば、Googleアカウントを使ってあるサービスにログインしたいとします。まず、（まだログインしていない場合）認証するために、サービスがGoogleにリダイレクトします。同意の画面が表示され、メールアドレスやコンタクトリストなどのデータ（保護されたリソース）にアクセスすることをサービスに許可するよう求められます。 /authorizeエンドポイントの要求パラメーターは次のとおりです。 アプリケーションがユーザーを認証するために/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と呼ばれています。任意のパラメーターで、以下の値を指定することができます。

​

トークンエンドポイント

/oauth/tokenエンドポイントは、アプリケーションがアクセストークンやリフレッシュトークンを取得するのに使用されます。アクセストークンが直接発行される暗黙フローを除いて、すべてのフローで使用されます。

• 認可コードフローでは、アプリケーションは、認可エンドポイントから取得した認可コードをアクセストークンと交換します。
• クライアントの資格情報フローとリソース所有者のパスワード資格情報付与交換では、アプリケーションは資格情報のセットを使って認証し、アクセストークンを取得します。

​

状態パラメーター

認可プロトコルはstateパラメーターを提供して、アプリケーションを以前の状態に復元できるようにします。stateパラメーターは、クライアントが認可要求で設定した状態オブジェクトの一部を保持して、応答でクライアントが使用できるようにします。状態パラメーターを使用する主な理由は、CSRF攻撃を軽減するためです。詳細については「OAuth 2.0の状態パラメーターを使用する」を参照してください。

​

もっと詳しく

• OAuth 2.0の状態パラメーターを使って攻撃を防ぎ、ユーザーをリダイレクトする
• どちらのOAuth 2.0フローを使用するべきですか？