RFC 6749 で定義されている認可フレームワークの標準仕様です。
4 つの役割が定義されています。
- 保護されたリソースへのアクセスを許可できるエンティティ
- リソースの所有者が人である場合はエンドユーザー
- 保護されたリソースをホストし、受け入れることができるサーバー
- アクセストークンを使用して保護されたリソース要求に応答
- リソースの所有者に代わって、その許可を得て保護されたリソースを要求するアプリケーション
- 「クライアント」という用語は、特定の実装特性を意味しない
- サーバー、デスクトップ、その他のデバイスで実行されるかどうかなどを意味しない
- リソースの所有者を認証し、承認を得た後、クライアントにアクセストークンを発行
- ID プロバイダー(IdP)とも呼ばれる
4 つの付与タイプが定義されています。
- 認可エンドポイントから短命の認可コードを発行し、トークンエンドポイントにて発行した認可コードと引き換えでアクセストークンを発行
- 認可コードはアクセストークンと更新トークンを取得するために使用される。
- パブリッククライアントの場合は、PKCE(Proof Key for Code Exchange)の利用も必要
- 「アクセス主体」には、Webアプリケーションが想定される
- 認可エンドポイントから直接アクセストークンを発行
- 「アクセス主体」には、SPA(Single Page Application)が想定される
OAuth 2.1
では非推奨
- トークンエンドポイントにトークンリクエストを投げ、応答としてアクセストークンを受け取る
- リソース所有者が、そのユーザー ID とパスワードをクライアントに提示
- 「アクセス主体」には、ブラウザを用いないアプリケーションが想定される
OAuth 2.1
では非推奨
- トークンエンドポイントにトークンリクエストを投げ、応答としてアクセストークンを受け取る
- クライアント資格情報(クライアント ID とクライアントシークレット)のみを使用してアクセストークンを要求
- クライアントとリソース所有者が同一の場合に使われる
- 「アクセス主体」には、ブラウザを用いないアプリケーションが想定される
保護されたリソースへのアクセスに使用される資格情報です。
アクセストークンは抽象化レイヤーを提供し、実装は認可サーバー依存です。
- アクセストークンに紐付く情報(権限や有効期限など)を認可サーバーで保持し、その情報を一意に特定できる識別子をアクセストークンとする
- アクセストークンに紐付く情報を提供するために、認可サーバーはイントロスペクション API(Introspection API)を提供する必要がある
- イントロスペクション API には、RFC 7662 という標準仕様が存在
- アクセストークンに紐付く情報(権限や有効期限など)をアクセストークン自体の中に埋め込む
- リソースサーバーは受け取ったアクセストークンが偽装されていないかを検証する必要がある
- 署名付きのアクセストークンを生成し、その署名を検証する方法が一般的
- 署名付きのアクセストークンの汎用形式として、RFC 7519 で規定される JWT(JSON Web Token)が一般的
識別子型と内包型の両方の特徴を持つ。
アクセストークンが無効または有効期限切れになったときに、新しいアクセストークンを取得するために使用される資格情報です。 更新トークンにも有効期限が存在するが、アクセストークンの有効期限よりも大幅に長いことが一般的である。 その為、セキュリティの考慮事項の制限も厳しい。
2 つのクライアントタイプが定義されています。
- 機密情報、認証情報の機密性を維持できるクライアント
- クライアントの認証情報へのアクセスが制限された安全なサーバに実装された Web アプリケーションなど
- クライアント登録時にクライアント識別子とクライアントシークレットを受け取る
- 機密情報、認証情報の機密性を維持できないクライアント
- インストールされたネイティブアプリケーションや Web ブラウザベースのアプリケーションなど
- クライアント登録時にクライアント識別子のみを受け取る
認可サーバーは基本的に 2 つのエンドポイントを提供します。
- クライアントがユーザーエージェントリダイレクトを介してリソース所有者から認可を得るために使用される
- 認可コード付与タイプと暗黙付与タイプで使用される
- クライアントがクライアント資格情報または、リフレッシュトークンを提示してアクセストークンを取得するために使用される
- 暗黙付与タイプを除くすべての付与タイプで使用される
RFC 7636 で定義されている OAuth 2.0
の拡張仕様です。
OAuth 2.0
のパブリッククライアントで可能な認可コード横取り攻撃への対策として策定されました。
悪意のあるアプリが何らかの方法で認可コードを含むカスタム URI を取得した場合、ユーザー固有のアクセストークンを横取りされる恐れがあります。
- クライアント側で
code_verifier
を生成し保管 code_challenge_method
で指定した方法(SHA256 など)でcode_verifier
からcode_challenge
を生成code_challenge
とcode_challenge_method
を追加してリクエスト- 認可サーバーは認可コードと紐付けて
code_challenge
とcode_challenge_method
を保管
- 認可コードに
code_verifier
を加えてリクエスト - 認可サーバーは
code_verifier
と、保管しているcode_challenge_method
からcode_challenge
を生成し、保管しているcode_challenge
と一致することを確認
RFC 7519 で定義されているコンパクトなクレーム表現形式です。
- JWT は JWS(JSON Web Signature)または、JWE(JSON Web Encryption)の形式で表現される
- ピリオド文字で区切られた一連の URL セーフパーツとして表される
- 各パーツは
base64url
でエンコードされた値が含まる - パーツの数は、JWS Compact Serialization の表現、または JWE Compact Serialization の表現に依存する
RFC 7515 で定義されている電子署名の表現形式です。
- JSON ベースのデータ構造を用いてコンテンツを電子署名する表示形式
- JWS コンパクト・シリアライゼーションと JWS JSON シリアライゼーションの2種類が定義されている
- 使用する暗号化アルゴリズムは JWA(JSON Web Algorithms)として RFC 7518 で定義されている
- Protected Header、Payload、Signature の 3 つのパーツをピリオド文字で連結して表現
- 各パーツは
base64url
でエンコードする
- Protected、Header、Payload、Signature の 4 つのパーツの一部またはすべてを含む JSON として表現
- Header 以外の各パーツは
base64url
でエンコードする
RFC 7516 で定義されている暗号化の表現形式です。
- JSON ベースのデータ構造を用いてコンテンツを暗号化する表示形式
- JWE コンパクト・シリアライゼーションと JWE JSON シリアライゼーションの2種類が定義されている
- Protected Header、Encrypted Key、Initialization Vector、Ciphertext、Authentication Tag の 5 つのパーツをピリオド文字で連結して表現
- 各パーツは
base64url
でエンコードする
- 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
でエンコードする