マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

※ このページは、ドラフト 15 を参考にして作成。

弱点

以下の弱点のために、

攻撃

以下の攻撃が可能。

対策

対策として、認可リクエストのパラメタ群をJWTで送信する
(認証要求に署名し、オプションで暗号化できる。)
OAuth 2.0 拡張OpenID Connectによって追加された。

効果

このアプリケーション層セキュリティの使用により、

Requestオブジェクト

内容

JWT化された認可リクエストのパラメタ群をRequestオブジェクトと呼ぶ。

生成方法

効果

クレームセット

Requestオブジェクト(JWT)のペイロードをbase64urlデコードした文字列。
認可Requestの全てのパラメタがRequestオブジェクトに同梱されている。

公開鍵

署名を検証する場合、JWK形式で表されるRSA公開鍵を使用する。

{
    "kty":"RSA",
    "kid":"k2bdc",
    "n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE5P
        7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF
        I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa
        ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR
        adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV
        W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
    "e":"AQAB"
}

渡し方

Requestオブジェクトの渡し方には "request" と "request_uri" の2つのパラメタを使用する方法がある。

requestパラメタ

Requestオブジェクトの値を直接渡す。

request_uriパラメタ

※ この場合、response_type, client_id, state値の同梱は不要。
(client_idにrequest_uriが対応していれば良い。)

実装

下記手順で取得したRequestオブジェクトを署名検証(若しくは復号)する。

復号化

Requestオブジェクトが暗号化されている場合、
下記手順で取得したRequestオブジェクトを復号化する。

復号化の処理

を取り出す。

復号化の失敗

復号化に失敗した場合、Authorization Serverは「invalid_request_object」エラーを返す。

署名検証

下記手順で取得したRequestオブジェクトを署名検証する。

署名検証の処理

署名検証の失敗

署名検証に失敗した場合、Authorization Serverは「invalid_request_object」エラーを返す。

パラメタ検証

Authorization Serverは、

追加エラー値

requestパラメタ

request_uriパラメタ

TLS要件

TLSをサポートしなければならない。

サーバ証明書要件

その他

セキュリティに関する考慮事項

ソース認証

認可リクエストの送信元は常に検証されなければならない。

Requestオブジェクトの暗号処理

request_uriとサーバ証明書

request_uriのサーバ証明書のIDを帯域外で知っている必要がある
(ただし、これは、一般的に信頼された方法ではない(ので後述が推奨?))。

request_uriとclient_idのバインド

Authorization Serverは、

Trust Framework Provider

上記エンドポイントがthird partyによって提供されても良い。

エンドポイント間のリンク

以下のエンドポイント間のリンクを張る拡張仕様が必要。
([FETT]で紹介されたクロスフェーズ攻撃を防止する)

  1. 認可エンドポイント( "authorization_endpoint")
  2. Redirect URI( "redirect_uri")
  3. Tokenエンドポイント( "token_endpoint")
  4. 保護されたリソース( "protected_resources")

request_uri関連のリスク

DDoS攻撃

不正なクライアントが、不正な"request_uri"を指定する。

Request URI Rewrite

(再帰的GET?)

対策

  1. "request_uri"パラメタの値が予期しない場所を指していないこと。
  2. 応答のコンテンツタイプが "application / jose"であること。
  3. request_uriの内容を取得するためのタイムアウトを実装すること。
  4. request_uriに対する再帰的GETを実行しないこと。

参考

??

(d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a third party that all the personal data requested is strictly necessary to perform the process that the end-user asked for, and statically signed by that third party. The authorization server then examines the signature and shows the conformance status to the end-user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances.

For example, the authorization server may provide a URL to which the client POSTs the request object and obtains the Requiest URI. This URI is the Request Object URI, "request_uri".


Tags: :認証基盤, :クレームベース認証, :OAuth


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS