OAuth 2.0 認可フレームワーク

Auth0がOAuth 2.0認可フレームワークとどのように連携するかを説明します。

Overview

主要概念

• Auth0は、Internet Engineering Task Force (IETF) が策定したOAuth 2.0プロトコルをサポートしています。
• OAuth 2.0仕様のロール、グラントタイプ (ワークフロー) 、エンドポイントについて確認できます。

OAuth 2.0 認可フレームワークは、ユーザーが長期的な認証情報やアイデンティティを開示することなく、サードパーティのウェブサイトやアプリケーションに保護されたリソースへのアクセスを許可できるプロトコルです。

OAuth

は認可レイヤーを導入し、クライアントの役割とリソースオーナーの役割を分離します。OAuthでは、クライアントはリソースオーナーが管理し、

リソースサーバー

がホストするリソースへのアクセスを

リソースオーナー

に要求し、リソースオーナーとは異なる認証情報が発行されます。保護されたリソースへのアクセスにリソースオーナーの認証情報を使用する代わりに、クライアントは

アクセストークン

(特定のスコープ、有効期間、その他のアクセス属性を示す文字列) を取得します。アクセストークンは、リソースオーナーの承認のもとに

認可サーバー

からサードパーティのクライアントに発行されます。クライアントはこのアクセストークンを使用して、リソースサーバーがホストする保護されたリソースにアクセスします。

Auth0は、APIの認可シナリオ向けにJSON Web Token (JWT) 形式でアクセストークンを生成します。アクセストークンが表す権限は、OAuthの用語ではスコープと呼ばれます。アプリケーションがAuth0で認証する際に必要なスコープを指定し、ユーザーによってそれらのスコープが認可されると、アクセストークンはその認可済みスコープを表します。

​

役割

OAuth 2.0 のフローには、次の役割があります。

• リソースオーナー: 保護されたリソースへのアクセスを許可できる主体です。通常はエンドユーザーを指します。
• リソースサーバー: 保護されたリソースを提供するサーバーです。つまり、アクセス先の API です。
• クライアント: リソースオーナー に代わって、保護されたリソースへのアクセスを要求するアプリケーションです。
• Authorization Server: リソースオーナー を認証し、適切な認可を得た後にアクセストークンを発行する認可サーバーです。この場合は Auth0 を指します。

​

Grant types

OAuth 2.0 では、アクセストークンを取得するための 4 つのフローが定義されています。これらのフローは グラントタイプ と呼ばれます。どのフローがユースケースに適しているかを判断するには、主にアプリケーションの種類を考慮します。

• Authorization Code Flow: サーバー上で実行される Web アプリで使用されます。モバイルアプリでも使用され、その場合は Proof Key for Code Exchange (PKCE) technique を利用します。
• Implicit Flow with Form Post: ユーザーのブラウザー上で実行される、JavaScript を中心としたアプリ (Single-Page Applications) で使用されます。
• Resource Owner Password Flow: 高い信頼性を前提とするアプリで使用されます。
• Client Credentials Flow: マシン間通信に使用されます。

この仕様では、追加の グラントタイプ を定義するための拡張メカニズムも提供されています。各 グラントタイプ の仕組みや、どのような場合に使用すべきかについて詳しくは、Authentication and Authorization Flows を参照してください。

​

エンドポイント

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

​

認可エンドポイント

/authorize エンドポイントは、リソース所有者とやり取りし、保護されたリソースへのアクセスに必要な認可を取得するために使用します。イメージしやすいように、Google アカウントを使ってあるサービスにログインする場合を考えてみてください。まず、そのサービスは認証のために Google にリダイレクトします (まだログインしていない場合) 。その後、同意画面が表示され、あなたの一部のデータ (保護されたリソース) へのアクセスをそのサービスに許可するよう求められます。たとえば、メールアドレスや連絡先リストです。

/authorize エンドポイントのリクエストパラメーターは次のとおりです。

Parameter	Description
response_type	認可サーバーに、どのグラントを実行するかを伝えます。
response_mode	(省略可能) 認可リクエストの結果の形式を指定します。値: - query: Authorization Code グラント用。302 Found によりリダイレクトされます。 - fragment: Implicit グラント用。302 Found によりリダイレクトされます。 - form_post: 200 OK。レスポンスパラメーターが hidden パラメーターとして HTML フォームに埋め込まれます。 - web_message: サイレント認証用。HTML5 の web messaging を使用します。
client_id	認可を要求するアプリケーションの ID です。
redirect_uri	URL を指定します。このエンドポイントからの正常なレスポンスでは、この URL にリダイレクトされます。
scope	アプリケーションが必要とする権限のスペース区切りリストです。
state	セキュリティ目的で使用される不透明な値です。このリクエストパラメーターが設定されている場合、redirect_uri の一部としてアプリケーションに返されます。
connection	パスワードレス接続の接続タイプを指定します

アプリケーションがユーザーを認証するために /authorize エンドポイントを最初に呼び出す際に、カスタムクエリパラメーターを設定できます。カスタムクエリパラメーターを使用すると、Universal Login エクスペリエンスのページテンプレートに追加のコンテキストを渡せます。

connection パラメーターを使用するには、ID First を有効にする必要があります。connection パラメーターと Universal Login エクスペリエンスの詳細については、Passwordless for Universal Login を参照してください。

ext- で始まるクエリパラメーターは、自動的に page template context に表示されます。

このエンドポイントは、Authorization Code および Implicit グラントタイプで使用されます。認可サーバーは、アプリケーションがどのグラントタイプを使うのかを把握する必要があります。これは、発行するクレデンシャルの種類に影響するためです。

• Authorization Code グラントでは、認可コードを発行します (後で /oauth/token エンドポイントでアクセストークンと交換できます) 。
• Implicit グラントでは、アクセストークンを発行します。これは不透明な文字列 (または Auth0 実装では JWT) で、どのアプリケーションに対して誰がどの権限 (スコープ) を認可したかを表します。

どのグラントタイプを使用するかを認可サーバーに伝えるには、response_type リクエストパラメーターを次のように使用します。

• Authorization Code グラントでは、認可コードを含めるために response_type=code を使用します。
• Implicit グラントでは、アクセストークンを含めるために response_type=token を使用します。別の方法として、アクセストークンと IDトークン の両方を含めるために response_type=id_token token を使用できます。

IDトークンは、ログインしているユーザーに関する情報を含む JWT です。これは OpenID Connect (OIDC) で導入されました。

OAuth 2.0 Multiple Response Type Encoding Practices specification では、認可リクエストの結果の形式を指定するパラメーターが追加されました。このパラメーターは response_mode と呼ばれます。省略可能で、次の値を取ります:

値	説明
query	これは Authorization Code グラントのデフォルトです。成功時のレスポンスは 302 Found で、redirect_uri へのリダイレクトが行われます。レスポンスパラメーターは、Location ヘッダー内の redirect_uri のクエリーコンポーネント (? の後の部分) に含まれます。 例: HTTP/1.1 302 Found Location: https://my-redirect-uri.callback?code=js89p2x1 (この場合、認可 code は js89p21 です) 。
fragment	これは Implicit グラントのデフォルトです。成功時のレスポンスは 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 Messaging を使用します。これは、Silent Authentication を使用する場合に特に有用です。このレスポンスモードを使用するには、Auth0 のアプリケーション設定にある Allowed Web Origins フィールドにアプリケーションの URL を登録する必要があります。

​

トークンエンドポイント

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

• Authorization Code Flow では、アプリケーションは認可エンドポイントから取得した認可コードをアクセストークンと交換します。
• Client Credentials Flow と Resource Owner Password Credentials Grant Exchange では、アプリケーションは一連の認証情報を使用して認証を行い、その後アクセストークンを取得します。

​

state パラメーター

認可プロトコルでは、アプリケーションの前の状態を復元するための state パラメーターが提供されています。state パラメーターは、認可リクエストでクライアントが設定した状態オブジェクトを保持し、その値をレスポンスでクライアントが利用できるようにします。state パラメーターを使用する主な目的は、CSRF 攻撃を軽減することです。詳細については、OAuth 2.0 の state パラメーターを使用するを参照してください。

​

詳しく見る

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