OAuth 2.0 仕様まとめ

RFC 6749（OAuth 2.0 Authorization Framework）およびRFC 6750（Bearer Token Usage）に基づく要点整理。

RFC用語（RFC 2119）

概要

OAuth 2.0は、サードパーティアプリケーションがHTTPサービスへの限定的なアクセスを取得するための認可フレームワーク。

従来のクライアント・サーバー認証モデルでは、サードパーティがリソースオーナーのクレデンシャルを直接使用する必要があった。OAuth 2.0はアクセストークンを導入することで、この問題を解決する。

4つのロール

sequenceDiagram
    participant RO as Resource Owner
    participant C as Client
    participant AS as Authorization Server
    participant RS as Resource Server

    C->>RO: (A) Authorization Request
    RO-->>C: (B) Authorization Grant
    C->>AS: (C) Authorization Grant
    AS-->>C: (D) Access Token
    C->>RS: (E) Access Token
    RS-->>C: (F) Protected Resource

4つのグラントタイプ

1. 認可コードグラント（Authorization Code）

最も推奨されるフロー。Webアプリケーション向け。

sequenceDiagram
    participant RO as Resource Owner
    participant UA as User Agent<br/>(Browser)
    participant C as Client
    participant AS as Authorization Server

    C->>UA: (A) Redirect to Authorization Endpoint
    UA->>AS: (A) Authorization Request<br/>(client_id, redirect_uri, scope, state)
    AS->>RO: (B) Authenticate & Authorize
    RO-->>AS: (B) Grant Access
    AS-->>UA: (C) Authorization Code
    UA-->>C: (C) Redirect with Code
    C->>AS: (D) Token Request<br/>(code, client_id, client_secret)
    AS-->>C: (E) Access Token<br/>(+ Refresh Token)

特徴:

• 認可コードは短命（RECOMMENDED: 10分以内）
• リフレッシュトークンの発行が可能
• クライアント認証を実施

2. インプリシットグラント（Implicit）

ブラウザ上で動作するJavaScriptアプリケーション向け。

sequenceDiagram
    participant RO as Resource Owner
    participant UA as User Agent<br/>(Browser)
    participant C as Client<br/>(JavaScript)
    participant AS as Authorization Server

    C->>UA: (A) Redirect to Authorization Endpoint
    UA->>AS: (A) Authorization Request<br/>(response_type=token)
    AS->>RO: (B) Authenticate & Authorize
    RO-->>AS: (B) Grant Access
    AS-->>UA: (C) Access Token in URL Fragment<br/>(#access_token=xxx)
    UA-->>C: (D) Extract Token from Fragment

注意: OAuth 2.1（ドラフト）ではセキュリティ上の理由から削除。PKCE付き認可コードグラントの使用を推奨。

3. リソースオーナーパスワードクレデンシャルグラント

クライアントがユーザーのID/パスワードを直接受け取るフロー。

sequenceDiagram
    participant RO as Resource Owner
    participant C as Client
    participant AS as Authorization Server

    RO->>C: (A) Username & Password
    C->>AS: (B) Token Request<br/>(grant_type=password,<br/>username, password)
    AS-->>C: (C) Access Token<br/>(+ Optional Refresh Token)

注意: OAuth 2.1（ドラフト）ではセキュリティ上の理由から削除。

4. クライアントクレデンシャルグラント

クライアント自身の権限でアクセスする場合のフロー。

sequenceDiagram
    participant C as Client
    participant AS as Authorization Server

    C->>AS: (A) Client Authentication<br/>(client_id, client_secret)
    AS-->>C: (B) Access Token

トークン

アクセストークン

リフレッシュトークン

sequenceDiagram
    participant C as Client
    participant AS as Authorization Server
    participant RS as Resource Server

    C->>AS: (A) Authorization Grant
    AS-->>C: (B) Access Token + Refresh Token

    C->>RS: (C) Access Token
    RS-->>C: (D) Protected Resource

    Note over C,RS: Time passes, token expires

    C->>RS: (E) Access Token (expired)
    RS-->>C: (F) Invalid Token Error

    C->>AS: (G) Refresh Token
    AS-->>C: (H) New Access Token<br/>(+ Optional New Refresh Token)

エンドポイント

認可エンドポイント（Authorization Endpoint）

リクエストパラメータ:

トークンエンドポイント（Token Endpoint）

リクエストパラメータ（認可コードグラント）:

レスポンス例:

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "scope": "read write"
}

スコープ

例:

scope=read write profile email

認可サーバーは要求されたスコープを完全に無視するか、部分的に許可するか、追加のスコープを付与してもよい。

Bearer Token（RFC 6750）

Bearer Tokenとは

トークンを所有する任意のパーティが、暗号鍵の所持を証明することなく利用可能なセキュリティトークン。

トークン送信方法

リソースサーバーはAuthorization Headerによる方法をサポートしなければならない（MUST）。

セキュリティ要件

セキュリティ考慮事項（RFC 6819より）

主要な脅威と対策

PKCE（RFC 7636）

インプリシットグラントに代わり、パブリッククライアント（SPAやモバイルアプリ）でも安全に認可コードグラントを使用するための拡張。

sequenceDiagram
    participant C as Client
    participant AS as Authorization Server

    Note over C: 1. Generate code_verifier<br/>(random string)
    Note over C: 2. Calculate code_challenge<br/>= SHA256(code_verifier)

    C->>AS: 3. Authorization Request<br/>(+ code_challenge)
    AS-->>C: Authorization Code

    C->>AS: 4. Token Request<br/>(code + code_verifier)
    Note over AS: 5. Verify:<br/>SHA256(code_verifier) == code_challenge
    AS-->>C: Access Token

現代的な推奨事項（OAuth 2.1）

OAuth 2.1はOAuth 2.0のベストプラクティスを統合したドラフト仕様。主な変更点：

推奨プラクティス

参考資料

• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6750: Bearer Token Usage
• RFC 6819: OAuth 2.0 Threat Model and Security Considerations
• RFC 7636: Proof Key for Code Exchange (PKCE)