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

1. はじめに (Introduction)

OAuthは、クライアントがリソース所有者の認証情報を直接使用するのではなく、アクセストークン (Access Token) を取得することによって保護されたリソースにアクセスすることを可能にします。アクセストークンは、「The OAuth 2.0 Authorization Framework」[RFC6749]において「クライアントに発行されたアクセス認可を表す文字列」として定義されています。

トークンは、リソース所有者の承認を得て、認可サーバー (Authorization Server) によってクライアントに発行されます。クライアントは、アクセストークンを使用して、リソースサーバー (Resource Server) がホストする保護されたリソースにアクセスします。本仕様は、OAuth アクセストークンがベアラートークン (Bearer Token) である場合に、保護されたリソースリクエストを行う方法を説明します。

本仕様は、トランスポート層セキュリティ (Transport Layer Security, TLS) [RFC5246]を使用したHTTP/1.1 [RFC2616]上でのベアラートークンの使用を定義し、保護されたリソースへのアクセスを可能にします。TLSは本仕様において実装し使用することが必須です (しなければならない)。他の仕様は、他のプロトコルでの使用のために本仕様を拡張してもよい (してもよい)。OAuth 2.0認可 [RFC6749]フローから得られたアクセストークンを使用してOAuth保護リソースにアクセスするために設計されていますが、本仕様は実際には、任意のソースからのベアラートークンを使用して、それらのベアラートークンによって保護された任意のリソースにアクセスするために使用できる一般的なHTTP認可方式を定義しています。Bearer認証スキームは、主にWWW-AuthenticateおよびAuthorization HTTPヘッダーを使用したサーバー認証を目的としていますが、プロキシ認証への使用を妨げるものではありません。

1.1. 表記規則 (Notational Conventions)​

この文書のキーワード「しなければならない (MUST)」、「してはならない (MUST NOT)」、「必須である (REQUIRED)」、「することになる (SHALL)」、「することはない (SHALL NOT)」、「すべきである (SHOULD)」、「すべきでない (SHOULD NOT)」、「推奨される (RECOMMENDED)」、「してもよい (MAY)」、「任意である (OPTIONAL)」は、「Key words for use in RFCs to Indicate Requirement Levels」[RFC2119]に記載されているように解釈されるものとします。

本文書は、[RFC5234]の拡張バッカス・ナウア記法 (Augmented Backus-Naur Form, ABNF) 表記を使用します。さらに、以下の規則がHTTP/1.1 [RFC2617]から含まれています: auth-param および auth-scheme; および「Uniform Resource Identifier (URI): Generic Syntax」[RFC3986]から: URI-reference。

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

1.2. 用語 (Terminology)​

ベアラートークン (Bearer Token) : トークンを所有する任意の当事者(「ベアラー」)が、それを所有する他の当事者と同じ方法でトークンを使用できるという特性を持つセキュリティトークン。ベアラートークンの使用には、ベアラーが暗号鍵材料の所有を証明すること(所有証明)は必要ありません。

その他のすべての用語は、「The OAuth 2.0 Authorization Framework」[RFC6749]で定義されているとおりです。

1.3. 概要 (Overview)​

OAuthは、クライアントがリソース所有者 (Resource Owner) に代わって保護されたリソースにアクセスするための方法を提供します。一般的なケースでは、クライアントが保護されたリソースにアクセスする前に、まずリソース所有者から認可許可 (Authorization Grant) を取得し、その後、認可許可をアクセストークンと交換しなければなりません。アクセストークンは、認可許可によって付与されたスコープ (Scope)、期間、およびその他の属性を表します。クライアントは、アクセストークンをリソースサーバーに提示することによって、保護されたリソースにアクセスします。場合によっては、クライアントは、最初にリソース所有者から認可許可を取得する必要なく、認可サーバーに直接自身の認証情報を提示してアクセストークンを取得できます。

アクセストークンは、リソースサーバーが理解する単一のトークンに対して、異なる認可構造(例えば、ユーザー名とパスワード、アサーション)を置き換える抽象化を提供します。この抽象化により、短期間有効なアクセストークンを発行できるようになり、また、リソースサーバーが幅広い認証スキームを理解する必要がなくなります。

  +--------+                               +---------------+
  |        |--(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フローは、クライアント、リソース所有者、認可サーバー、およびリソースサーバー間の相互作用を説明しています([RFC6749]で説明)。以下の2つのステップは、本文書内で規定されています:

(E) クライアントは、リソースサーバーに保護されたリソースを要求し、アクセストークンを提示することによって認証します。

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

本文書は、ステップ(D)で返されるアクセストークンに対する意味的要件も課しています。

に最終更新