Skip to content

Instantly share code, notes, and snippets.

@minazou67

minazou67/oauth-2.0-overview.md

Last active September 10, 2021 07:10
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save minazou67/bb4d37bed69e9e0748e1d46c55a7bb30 to your computer and use it in GitHub Desktop.
Save minazou67/bb4d37bed69e9e0748e1d46c55a7bb30 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
oauth-2.0-overview.md

The OAuth 2.0 Authorization Framework Overview

RFC 6749 で定義されている認可フレームワークの標準仕様です。

1 Roles（役割）

4 つの役割が定義されています。

1.1 Resource Owner（リソース所有者）

  • 保護されたリソースへのアクセスを許可できるエンティティ
  • リソースの所有者が人である場合はエンドユーザー

1.2. Resource Server（リソースサーバー）

  • 保護されたリソースをホストし、受け入れることができるサーバー
  • アクセストークンを使用して保護されたリソース要求に応答

1.3. Client（クライアント）

  • リソースの所有者に代わって、その許可を得て保護されたリソースを要求するアプリケーション
  • 「クライアント」という用語は、特定の実装特性を意味しない
    • サーバー、デスクトップ、その他のデバイスで実行されるかどうかなどを意味しない

1.4. Authorization Server（認可サーバー）

  • リソースの所有者を認証し、承認を得た後、クライアントにアクセストークンを発行
  • ID プロバイダー（IdP）とも呼ばれる

2. Authorization Grant（認可付与）

4 つの付与タイプが定義されています。

2.1. Authorization Code（認可コード）

  • 認可エンドポイントから短命の認可コードを発行し、トークンエンドポイントにて発行した認可コードと引き換えでアクセストークンを発行
    • 認可コードはアクセストークンと更新トークンを取得するために使用される。
  • パブリッククライアントの場合は、PKCE（Proof Key for Code Exchange）の利用も必要
  • 「アクセス主体」には、Webアプリケーションが想定される

2.2. Implicit（暗黙）

  • 認可エンドポイントから直接アクセストークンを発行
  • 「アクセス主体」には、SPA（Single Page Application）が想定される
  • OAuth 2.1 では非推奨

2.3. Resource Owner Password Credentials（リソース所有者パスワード資格情報）

  • トークンエンドポイントにトークンリクエストを投げ、応答としてアクセストークンを受け取る
  • リソース所有者が、そのユーザー ID とパスワードをクライアントに提示
  • 「アクセス主体」には、ブラウザを用いないアプリケーションが想定される
  • OAuth 2.1 では非推奨

2.4. Client Credentials（クライアント資格情報）

  • トークンエンドポイントにトークンリクエストを投げ、応答としてアクセストークンを受け取る
  • クライアント資格情報（クライアント ID とクライアントシークレット）のみを使用してアクセストークンを要求
  • クライアントとリソース所有者が同一の場合に使われる
  • 「アクセス主体」には、ブラウザを用いないアプリケーションが想定される

3. Access Token（アクセストークン）

保護されたリソースへのアクセスに使用される資格情報です。
アクセストークンは抽象化レイヤーを提供し、実装は認可サーバー依存です。

3.1. 識別子型

  • アクセストークンに紐付く情報（権限や有効期限など）を認可サーバーで保持し、その情報を一意に特定できる識別子をアクセストークンとする
  • アクセストークンに紐付く情報を提供するために、認可サーバーはイントロスペクション API（Introspection API）を提供する必要がある
  • イントロスペクション API には、RFC 7662 という標準仕様が存在

3.2. 内包型

  • アクセストークンに紐付く情報（権限や有効期限など）をアクセストークン自体の中に埋め込む
  • リソースサーバーは受け取ったアクセストークンが偽装されていないかを検証する必要がある
  • 署名付きのアクセストークンを生成し、その署名を検証する方法が一般的
  • 署名付きのアクセストークンの汎用形式として、RFC 7519 で規定される JWT（JSON Web Token）が一般的

3.3. ハイブリッド型

識別子型と内包型の両方の特徴を持つ。

4. Refresh Token（更新トークン）

アクセストークンが無効または有効期限切れになったときに、新しいアクセストークンを取得するために使用される資格情報です。 更新トークンにも有効期限が存在するが、アクセストークンの有効期限よりも大幅に長いことが一般的である。 その為、セキュリティの考慮事項の制限も厳しい。

5. Client Types（クライアントの種類）

2 つのクライアントタイプが定義されています。

5.1. Confidential clients（機密クライアント）

  • 機密情報、認証情報の機密性を維持できるクライアント
    • クライアントの認証情報へのアクセスが制限された安全なサーバに実装された Web アプリケーションなど
  • クライアント登録時にクライアント識別子とクライアントシークレットを受け取る

5.2. Public Clients（パブリッククライアント）

  • 機密情報、認証情報の機密性を維持できないクライアント
    • インストールされたネイティブアプリケーションや Web ブラウザベースのアプリケーションなど
  • クライアント登録時にクライアント識別子のみを受け取る

6. Protocol Endpoints（プロトコルエンドポイント）

認可サーバーは基本的に 2 つのエンドポイントを提供します。

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

  • クライアントがユーザーエージェントリダイレクトを介してリソース所有者から認可を得るために使用される
  • 認可コード付与タイプと暗黙付与タイプで使用される

6.2. Token endpoint（トークンエンドポイント）

  • クライアントがクライアント資格情報または、リフレッシュトークンを提示してアクセストークンを取得するために使用される
  • 暗黙付与タイプを除くすべての付与タイプで使用される

7. PKCE（Proof Key for Code Exchange by OAuth Public Clients）

RFC 7636 で定義されている OAuth 2.0 の拡張仕様です。

OAuth 2.0 のパブリッククライアントで可能な認可コード横取り攻撃への対策として策定されました。 悪意のあるアプリが何らかの方法で認可コードを含むカスタム URI を取得した場合、ユーザー固有のアクセストークンを横取りされる恐れがあります。

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

  • クライアント側で code_verifier を生成し保管
  • code_challenge_method で指定した方法（SHA256 など）で code_verifier から code_challenge を生成
  • code_challenge と code_challenge_method を追加してリクエスト
  • 認可サーバーは認可コードと紐付けて code_challenge と code_challenge_method を保管

7.2. Token endpoint（トークンエンドポイント）

  • 認可コードに code_verifier を加えてリクエスト
  • 認可サーバーは code_verifier と、保管している code_challenge_method から code_challenge を生成し、保管している code_challenge と一致することを確認

8. JWT（JSON Web Token）

RFC 7519 で定義されているコンパクトなクレーム表現形式です。

  • JWT は JWS（JSON Web Signature）または、JWE（JSON Web Encryption）の形式で表現される
  • ピリオド文字で区切られた一連の URL セーフパーツとして表される
  • 各パーツは base64url でエンコードされた値が含まる
  • パーツの数は、JWS Compact Serialization の表現、または JWE Compact Serialization の表現に依存する

9. JWS（JSON Web Signature）

RFC 7515 で定義されている電子署名の表現形式です。

  • JSON ベースのデータ構造を用いてコンテンツを電子署名する表示形式
  • JWS コンパクト・シリアライゼーションと JWS JSON シリアライゼーションの2種類が定義されている
  • 使用する暗号化アルゴリズムは JWA（JSON Web Algorithms）として RFC 7518 で定義されている

9.1. JWS Compact Serialization（JWS コンパクト・シリアライゼーション）

  • Protected Header、Payload、Signature の 3 つのパーツをピリオド文字で連結して表現
  • 各パーツは base64url でエンコードする

9.2. JWS JSON Serialization（JWS JSON シリアライゼーション）

  • Protected、Header、Payload、Signature の 4 つのパーツの一部またはすべてを含む JSON として表現
  • Header 以外の各パーツは base64url でエンコードする

10. JWE（JSON Web Encryption）

RFC 7516 で定義されている暗号化の表現形式です。

  • JSON ベースのデータ構造を用いてコンテンツを暗号化する表示形式
  • JWE コンパクト・シリアライゼーションと JWE JSON シリアライゼーションの2種類が定義されている

10.1. JWE Compact Serialization（JWE コンパクト・シリアライゼーション）

  • Protected Header、Encrypted Key、Initialization Vector、Ciphertext、Authentication Tag の 5 つのパーツをピリオド文字で連結して表現
  • 各パーツは base64url でエンコードする

10.2. JWE JSON Serialization（JWE JSON シリアライゼーション）

  • Protected Header、Shared Unprotected Header、Per-Recipient Unprotected Header、Encrypted Key、Initialization Vector、Ciphertext、Authentication Tag、AAD の 8 つのパーツの一部またはすべてを含む JSON として表現
  • Shared Unprotected Header、Per-Recipient Unprotected Header 以外の各パーツは base64url でエンコードする
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment