メインコンテンツまでスキップ

1. はじめに (Introduction)

従来のクライアント-サーバー認証モデルでは、クライアント (Client) がサーバー上のアクセス制限されたリソース (保護されたリソース, Protected Resource) をリクエストする際、リソースオーナー (Resource Owner) の認証情報 (Credentials) を使用してサーバーに認証を行います。サードパーティアプリケーションに制限されたリソースへのアクセスを提供するために、リソースオーナーはその認証情報をサードパーティと共有する必要があります。これにより、いくつかの問題と制限が生じます。

  • サードパーティアプリケーションは、将来の使用のためにリソースオーナーの認証情報を保存する必要があります。通常は平文のパスワードです。

  • サーバーは、パスワードに固有のセキュリティ上の弱点があるにもかかわらず、パスワード認証をサポートする必要があります。

  • サードパーティアプリケーションは、リソースオーナーの保護されたリソースに対して過度に広範なアクセス権を取得し、リソースオーナーは使用期間や限定されたリソースサブセットへのアクセスを制限する能力を失います。

  • リソースオーナーは、すべてのサードパーティへのアクセスを取り消さずに個別のサードパーティへのアクセスを取り消すことができず、サードパーティのパスワードを変更することによってのみ取り消すことができます。

  • 任意のサードパーティアプリケーションのセキュリティ侵害は、エンドユーザーのパスワードおよびそのパスワードによって保護されているすべてのデータの侵害につながります。

OAuth (オーオース) は、認可レイヤー (Authorization Layer) を導入し、クライアントの役割とリソースオーナーの役割を分離することで、これらの問題に対処します。OAuth では、クライアントはリソースオーナーによって制御され、リソースサーバー (Resource Server) によってホストされているリソースへのアクセスをリクエストし、リソースオーナーの認証情報とは異なる認証情報のセットが発行されます。

リソースオーナーの認証情報を使用して保護されたリソースにアクセスする代わりに、クライアントはアクセストークン (Access Token) を取得します。アクセストークンは、特定のスコープ (Scope)、ライフタイム、およびその他のアクセス属性を示す文字列です。アクセストークンは、リソースオーナーの承認を得て、認可サーバー (Authorization Server) によってサードパーティクライアントに発行されます。クライアントは、アクセストークンを使用して、リソースサーバーによってホストされている保護されたリソースにアクセスします。

たとえば、エンドユーザー (リソースオーナー) は、写真共有サービス (リソースサーバー) に保存されている保護された写真へのアクセスを印刷サービス (クライアント) に許可できます。その際、ユーザー名とパスワードを印刷サービスと共有する必要はありません。代わりに、ユーザーは写真共有サービスによって信頼されているサーバー (認可サーバー) で直接認証を行い、そのサーバーが印刷サービスに委任固有の認証情報 (アクセストークン) を発行します。

本仕様は HTTP (<RFC2616>) での使用を想定して設計されています。HTTP 以外のプロトコル上での OAuth の使用は、本仕様の範囲外です。

OAuth 1.0 プロトコル (<RFC5849>) は情報提供文書として公開され、小規模なアドホックコミュニティの努力の結果でした。この Standards Track 仕様は、OAuth 1.0 の展開経験、およびより広範な IETF コミュニティから収集された追加のユースケースと拡張性要件の上に構築されています。OAuth 2.0 プロトコルは OAuth 1.0 との後方互換性がありません。2つのバージョンはネットワーク上で共存する可能性があり、実装は両方をサポートすることを選択できます。ただし、本仕様の意図は、新しい実装が本文書で指定されている OAuth 2.0 をサポートし、OAuth 1.0 は既存の展開をサポートするためにのみ使用されることです。OAuth 2.0 プロトコルは、OAuth 1.0 プロトコルと実装の詳細をほとんど共有していません。OAuth 1.0 に精通している実装者は、その構造と詳細について何も仮定せずに本文書に取り組むべきです (SHOULD)。

1.1. 役割 (Roles)​

OAuth は4つの役割を定義します。

リソースオーナー (Resource Owner)
保護されたリソースへのアクセスを許可できるエンティティ。リソースオーナーが個人である場合、エンドユーザー (End-User) と呼ばれます。

リソースサーバー (Resource Server)
保護されたリソースをホストするサーバー。アクセストークンを使用した保護されたリソースのリクエストを受け入れ、応答することができます。

クライアント (Client)
リソースオーナーに代わって、その認可を得て保護されたリソースのリクエストを行うアプリケーション。「クライアント」という用語は、特定の実装特性 (たとえば、アプリケーションがサーバー、デスクトップ、またはその他のデバイスで実行されるかどうか) を意味するものではありません。

認可サーバー (Authorization Server)
リソースオーナーの認証に成功し、認可を取得した後、クライアントにアクセストークンを発行するサーバー。

認可サーバーとリソースサーバー間のインタラクションは、本仕様の範囲を超えています。認可サーバーは、リソースサーバーと同じサーバーである場合もあれば、別のエンティティである場合もあります。単一の認可サーバーが、複数のリソースサーバーによって受け入れられるアクセストークンを発行することができます (MAY)。

1.2. プロトコルフロー (Protocol Flow)​

以下の図は、4つの役割間の抽象的な OAuth 2.0 フローを示し、図の矢印間で必要なステップを示しています。

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

図1: 抽象プロトコルフロー

図1に示す抽象的な OAuth 2.0 フローは、以下のステップを説明しています。

(A) クライアントは、リソースオーナーに認可をリクエストします。認可リクエストは、リソースオーナーに直接行うことができます (図のように)、または認可サーバーを仲介として行うことが望ましいです (SHOULD)。

(B) クライアントは、認可グラント (Authorization Grant) を受け取ります。認可グラントは、リソースオーナーの認可を表す認証情報であり、本仕様で定義されている4つの許可タイプのいずれか、または拡張許可タイプを使用して表現されます。認可許可タイプは、クライアントが認可をリクエストするために使用するメソッドと、認可サーバーがサポートするタイプによって異なります。

(C) クライアントは、認可サーバーで認証を行い、認可グラントを提示することによってアクセストークンをリクエストします。

(D) 認可サーバーは、クライアントを認証し、認可グラントを検証します。有効である場合、アクセストークンを発行します。

(E) クライアントは、リソースサーバーから保護されたリソースをリクエストし、アクセストークンを提示して認証を行います。

(F) リソースサーバーは、アクセストークンを検証します。有効である場合、リクエストを処理します。

認可サーバーを介してリソースオーナーから認可を取得する望ましい方法は、認可サーバーを仲介として使用することです。これについては、セクション4.1および4.2で説明されています。

1.3. 認可グラント (Authorization Grant)​

認可グラント (Authorization Grant) は、リソースオーナーの認可 (保護されたリソースへのアクセス許可) を表す認証情報であり、クライアントがアクセストークンを取得するために使用します。本仕様では、4つの許可タイプ (認可コード、インプリシット、リソースオーナーパスワードクレデンシャル、およびクライアントクレデンシャル) と、追加のタイプを定義するための拡張メカニズムを定義しています。

1.3.1. 認可コード (Authorization Code)​

認可コード (Authorization Code) は、認可サーバーを仲介としてクライアントとリソースオーナーの間で使用することによって取得されます。クライアントがリソースオーナーに直接認可をリクエストする代わりに、クライアントはリソースオーナーを認可サーバーに誘導します (RFC 2616で定義されているユーザーエージェント経由)。認可サーバーは、リソースオーナーを認可コードとともにクライアントに戻します。

クライアントがアクセストークンを取得するためにリソースオーナーを認可コードとともにクライアントに戻す前に、認可サーバーはリソースオーナーを認証し、認可を取得します。リソースオーナーはクライアントではなく認可サーバーでのみ認証を行うため、リソースオーナーの認証情報がクライアントと共有されることはありません。

認可コードにはいくつかの重要なセキュリティ上の利点があります。たとえば、クライアントを認証する能力、アクセストークンをクライアントに直接送信する能力 (リソースオーナーが使用するユーザーエージェント経由で送信する可能性があり、他者に公開される可能性があるため)。

1.3.2. インプリシット (Implicit)​

インプリシット許可 (Implicit Grant) は、認可コードフローの簡略化されたバージョンであり、JavaScript などのスクリプト言語を使用してブラウザで実装されるクライアント向けに最適化されています。インプリシットフローでは、認可コードをクライアントに発行する代わりに、クライアントにアクセストークンが直接発行されます (リソースオーナーの認可の結果として)。許可タイプは暗黙的です。なぜなら、認可コードなどの中間認証情報は発行されず (後でアクセストークンを取得するために使用されます)、クライアントに直接発行されるためです。

インプリシット許可タイプを発行する場合、認可サーバーはクライアント認証を行いません。場合によっては、クライアント ID はリダイレクト URI を介して検証できます。リダイレクト URI はクライアントに配信するために使用されます。アクセストークンはリダイレクト URI でエンコードされる可能性があるため、リソースオーナーまたはユーザーエージェントと同じデバイス上の他のアプリケーションに公開される可能性があります。

1.3.3. リソースオーナーパスワードクレデンシャル (Resource Owner Password Credentials)​

リソースオーナーパスワードクレデンシャル (Resource Owner Password Credentials) (すなわち、ユーザー名とパスワード) は、アクセストークンを取得するための認可グラントとして直接使用できます。この認証情報は、リソースオーナーとクライアント間に高い信頼度が存在する場合 (たとえば、クライアントがデバイスのオペレーティングシステムの一部である場合や、高い特権を持つアプリケーションである場合)、および他の認可許可タイプが利用できない場合 (たとえば、レガシークライアントなど) にのみ使用すべきです (SHOULD)。

この許可タイプはクライアントに直接認証情報としてパスワードを使用させますが、単一のリクエストでクライアントにアクセストークンを交換して使用します。この許可タイプは、将来の使用のためにクライアントが認証情報を保存する必要性を排除します。これは、長期間有効なアクセストークンまたはリフレッシュトークンと交換することによって実現できます。

1.3.4. クライアントクレデンシャル (Client Credentials)​

クライアントクレデンシャル (Client Credentials) (またはその他の形式のクライアント認証) は、認可のスコープがクライアントの制御下にある保護されたリソース、または以前に認可サーバーと調整された保護されたリソースに限定されている場合、認可グラントとして使用できます。クライアントクレデンシャルは通常、クライアントが自分自身に代わって (クライアントがリソースオーナーでもある場合)、またはリソースオーナーと認可サーバーで以前に調整された保護されたリソースへのアクセスを要求する場合に、認可グラントとして使用されます。

1.4. アクセストークン (Access Token)​

アクセストークン (Access Token) は、保護されたリソースにアクセスするために使用される認証情報です。アクセストークンは、リソースオーナーによって許可された特定のスコープとアクセス期間を表す文字列であり、リソースサーバーと認可サーバーによって強制されます。

トークンは、アクセス認可情報を取得するために使用される認可情報を識別する識別子を表すことも、アクセス認可情報を検証可能な方法で自己完結的に含めることもできます (すなわち、署名を持つデータを含むトークン文字列)。

アクセストークンを使用して認証を行い、保護されたリソースにアクセスするために、クライアントには追加の認証認証情報が必要になる場合があります。これについては、本仕様の範囲外です。

アクセストークンは、リソースサーバーが理解するために必要な属性をカプセル化するための抽象化レイヤーを提供します。トークンは、認可情報を単一のトークンに統合することで、リソースサーバーがさまざまな認証方法を理解する必要性を排除する抽象化レイヤーを表します。

アクセストークンは、異なるフォーマット、構造、および利用方法 (たとえば、暗号化プロパティ) を持つことができます (たとえば、リソースサーバーのセキュリティ要件に基づいて)。アクセストークンの属性と、保護されたリソースにアクセスするために使用するメソッドは、セクション7で定義されているアクセストークンタイプによって定義されます。

1.5. リフレッシュトークン (Refresh Token)​

リフレッシュトークン (Refresh Token) は、アクセストークンを取得するために使用される認証情報です。リフレッシュトークンは、現在のアクセストークンが無効になったり期限切れになったりした場合に、追加のアクセストークンを取得するために認可サーバーによってクライアントに発行されます。また、同等またはより狭いスコープ (アクセストークンは、元のグラントによって付与されたスコープよりも狭いスコープを持つ場合があります) を持つ追加のアクセストークンを取得するためにも使用できます。リフレッシュトークンの発行はオプションであり、認可サーバーの裁量に委ねられます。認可サーバーがリフレッシュトークンを発行する場合、アクセストークン (セクション5.1を参照) を発行する際にリフレッシュトークンが含まれます。

リフレッシュトークンは、リソースオーナーによって許可された認可を表す文字列です。文字列は通常、クライアントに対して不透明です。トークンは、アクセス認可情報を取得するために使用される認可情報を識別する識別子を示します。アクセストークンとは異なり、リフレッシュトークンは認可サーバーでのみ使用され、リソースサーバーに送信されることはありません。

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

図2: リフレッシュトークン (Refreshing an Expired Access Token)

図2に示すフローには、以下のステップが含まれます。

(A) クライアントは、認可サーバーで認証を行い、認可グラントを提示することによってアクセストークンをリクエストします。

(B) 認可サーバーは、クライアントを認証し、認可グラントを検証します。有効である場合、アクセストークンとリフレッシュトークンを発行します。

(C) クライアントは、アクセストークンを提示してリソースサーバーから保護されたリソースをリクエストします。

(D) リソースサーバーは、アクセストークンを検証します。有効である場合、リクエストを処理します。

(E) ステップ (C) と (D) は、アクセストークンが期限切れになるまで繰り返されます。アクセストークンが無効であることをクライアントが認識している場合、ステップ (G) にスキップします。それ以外の場合は、別の保護されたリソースリクエストを行います。

(F) アクセストークンが無効であるため、リソースサーバーは無効なトークンエラーを返します。

(G) クライアントは、認可サーバーで認証を行い、リフレッシュトークンを提示することによって新しいアクセストークンをリクエストします。クライアント認証要件は、クライアントタイプと認可サーバーのポリシーに基づいています。

(H) 認可サーバーは、クライアントを認証し、リフレッシュトークンを検証します。有効である場合、新しいアクセストークン (およびオプションで新しいリフレッシュトークン) を発行します。

ステップ (C)、(D)、(E)、および (F) は本仕様の範囲外です。これらについては、RFC 6750で説明されています。

1.6. TLS バージョン​

この仕様全体を通して、TLS は Transport Layer Security の略で、クライアントとサーバー間で通信チャネルを保護するために使用されます。この仕様の適用可能な推奨事項は、TLS のバージョン1.0 <RFC2246>、1.1 <RFC4346>、および 1.2 <RFC5246> に適用されます。

1.7. HTTP リダイレクション​

この仕様では、HTTP リダイレクションを多用しています。このメカニズムを通じて、クライアントはリソースオーナーのユーザーエージェントを別の宛先に誘導します。リダイレクション先は通常、認可サーバーですが、後でリソースオーナーのユーザーエージェントをクライアントにリダイレクトします。このリダイレクションが成功するためには、リソースオーナーのユーザーエージェントがリダイレクションをサポートし、クライアントと認可サーバー間でリダイレクション URI を交換する必要があります。

1.8. 相互運用性 (Interoperability)​

OAuth 2.0 は、さまざまなクライアントタイプに対して豊富な認可フレームワークを提供します。また、多数のオプション実装オプションを定義しています。多くのオプション実装オプションは、拡張性のために保持されているためです。このドキュメント全体で、実装要件とオプション機能が明確に指定されています。

さらに、この仕様は、「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」などのキーワードを、<RFC2119>の定義に従って使用しています。

1.9. 表記規則 (Notational Conventions)​

この仕様のキーワード「しなければならない (MUST)」、「してはならない (MUST NOT)」、「必須である (REQUIRED)」、「しなければならない (SHALL)」、「してはならない (SHALL NOT)」、「すべきである (SHOULD)」、「すべきでない (SHOULD NOT)」、「推奨される (RECOMMENDED)」、「してもよい (MAY)」、「任意である (OPTIONAL)」は、<RFC2119>に記載されているとおりに解釈されるものとします (are to be interpreted)。

この仕様では、Augmented Backus-Naur Form (ABNF) 表記法を使用しています。さらに、HTTP/1.1 <RFC2616> の「quoted-string」および「URI-reference」というルールが含まれています。

特に明記されていない限り、すべてのプロトコルパラメータ名と値は大文字と小文字を区別します。

に最終更新