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

1. Introduction (はじめに)

1. Introduction (はじめに)​

OAuth 2.0 [RFC6749] における認可リクエストはクエリパラメータのシリアル化を用い, 通常 Web ブラウザなどのユーザエージェント経由で送られる.

例として, パラメータ response_type, client_id, state, redirect_uri がリクエストの URI にエンコードされる:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

実装は容易だが, URI へのエンコードではアプリケーション層のセキュリティで機密性と整合性を提供できない. TLS はクライアントとユーザエージェント間, およびユーザエージェントと認可サーバ間の通信保護に用いられるが, TLS セッションはユーザエージェントで終端する. さらに TLS セッションはミドルボックス (ロードバランサなど) で早期に終端されうる.

その結果, [RFC6749] の認可リクエストには次の欠点がある:

(a) ユーザエージェント経由の通信に整合性保護がなく, パラメータが改ざんされうる (整合性保護の失敗).

(b) 通信の発信元が認証されない (発信元認証の失敗).

(c) ユーザエージェント経由の通信が監視されうる (封じ込め/機密性の失敗).

これらの固有の弱点により, リダイレクト URI の書き換えなど, プロトコルに対する複数の攻撃が指摘されている.

アプリケーション層のセキュリティはこれらの問題を緩和する.

アプリケーション層のセキュリティにより, 信頼できる第三者がリクエストを準備でき, クライアントアプリケーションが事前に合意した以上の権限を要求できなくなる.

さらに, 参照による転送は線路上のオーバーヘッドを削減できる.

JWT [RFC7519] エンコーディングが選ばれた理由は次のとおり:

(1) OAuth のレスポンス形式に用いられる JSON との密接な関係

(2) テキスト形式による開発者への親しみやすさ

(3) XML との比較での相対的なコンパクトさ

(4) Proposed Standard としての位置づけ, および関連する署名と暗号化方式 [RFC7515] [RFC7516]

(5) XML Signature および Encryption と比較した JWS と JWE の容易さ

パラメータ request と request_uri は OAuth 2.0 [RFC6749] フロー向けの追加の認可リクエストパラメータとして導入される. request パラメータは JSON Web Token (JWT) [RFC7519] であり, その JWT Claims Set に JSON エンコードされた OAuth 2.0 認可リクエストパラメータが入る. RFC 7519 とは対照的に, Claims Set の要素はエンコードされた OAuth リクエストパラメータ [IANA.OAuth.Parameters] であり, IANA 管理の JSON Web Token クレーム [IANA.JWT.Claims] のうち iss と aud など少数だけが補足的に加わる. request パラメータ内の JWT は JWS により整合性保護および発信元認証が行われる.

JWT [RFC7519] は参照により認可エンドポイントへ渡すこともでき, その場合は request の代わりにパラメータ request_uri を用いる.

クエリパラメータの代わりに JWT [RFC7519] をリクエストのエンコーディングに用いる利点は次のとおり:

(a) 整合性保護. リクエストに署名し整合性を検証できる.

(b) 発信元認証. リクエストに署名し署名者を認証できる.

(c) 機密性保護. リクエストを暗号化し, TLS 接続が (ユーザエージェントを含む) どこかで終端していてもエンドツーエンドの機密性を提供できる.

(d) 収集の最小化. 信頼できる第三者が認可リクエストが一定の方針に適合することを証明する署名を付けられる. 例えば, エンドユーザーが求めた処理に厳密に必要な個人データだけが要求されているか, 信頼できる第三者が事前に審査し, その第三者がリクエストに署名する. 認可サーバは署名を検証し, 適合状況をエンドユーザーに示し, 認可時にリクエストの正当性について一定の保証を与えられる. 場合によってはそのような状況下で認可ダイアログを省略してもよい.

参照によるリクエストが有用な例は次のとおり:

  1. 転送するリクエストのサイズを小さくしたいとき. アプリケーション層のセキュリティ, 特に公開鍵暗号を用いるとリクエストサイズが増える.

  2. クライアントがアプリケーション層の暗号処理を行いたくないとき. 認可サーバはクライアントとの直接通信で認可リクエストを受け付けるエンドポイントを提供でき, クライアントは認証されチャネルは TLS で保護される.

OpenID Connect [OpenID.Core] がこの能力を用いている.

1.1. Requirements Language (要件言語) を参照のこと.

に最終更新