web-dev-qa-db-ja.com

OAuth 2.0では、BearerトークンをHMACに置き換えるとどのように機能し、クライアント/サーバーはどのように検証されますか？

このPluralsightクラスはベアラートークンについて説明しています 、およびOAuth 2.0から欠落しているものの1つはHMACベースの検証です。thinktectureブログの他の場所では、これらはPoPトークン（所持証明書）

HMACベースの検証は、ベアラートークンの交換がなりすましとなるCSRFベースの攻撃を防ぎます。

私を混乱させたのは、OAuth 2.0リスクに関するスライドの1つで、この検証はクライアントで行われることになるということです。

HMACベースの検証がOAuth仕様に追加されたことは一度もありませんでした。その省略が、EAuthの元の作者であるEran Hammerが仕様から名前を削除することを決定した主な理由でした。

これについてさらに詳しく説明すると、OAuthのHMACトークンが次のようになる方法について少し混乱しています。

  1. codeまたはimplicitフローで構築されます
  2. クライアントはこれらのHMACトークンをどのように検証しますか？これはSPAアプリケーションに関するものだけだと思いますか？
  3. OpenID ConnectのJWT構成は、OAuth 2.0のすべてのHMACの問題を解決しますか？
authenticationoauthcsrfauthorizationopenid-connect
6
goodguys_activate

フローが何であれ、MACトークンは同じように生成されます。対称秘密鍵とIDがクライアントに送信されますonce。この秘密は、ネットワーク経由で送信されることはありません。

クライアントはトークンを検証しません*、クライアントはベアラートークンを使用するのと同じようにそれを使用します。ただし、シークレットはネットワーク経由で送信されないため、リークできません。

  +--------------+                                        +--------------+
  |              |>------Request with authenticator------>|              |
  |              |                                        |   Resource   |
  |    Client    |                                        |    server    |
  |              |<--------Requested resource------------<|              |
  |              |                                        +--------------+
  +--------------+                                                ^
         ^                                                        |
         |                                                        |
         |                                                        |
         |                                                        |
         |                                                 MAC algorithm  
   MAC algorithm                                           over key+params
   over key+params

クライアントは、秘密鍵といくつかのパラメーター（トークンID、nonce、タイムスタンプ、その他のデータを含む）を使用してMACを計算する認証子を構築し、それをリクエストに添付します。

リソースサーバー（またはRSがトークンの検証に使用する3番目のサーバー）はこの秘密キーを知っているため、クライアントが同じパラメーターを使用して行ったのと同じ計算を実行します。すべてが一致する場合は、リクエストを続行します。

サーバーは、タイムスタンプをチェックしてノンスの再利用を防止することにより、リプレイ攻撃を防止する役割も果たします。

これにより、トークンが漏えいする可能性のある多くのシナリオが再び保護されます：TLSの構成ミス/バグ、攻撃者がクライアントのデータベースに侵入するエンドポイントなど。

3番目の質問については、はいといいえ。 OAuth2 MAC仕様ドラフト は、JWTがJWTを使用してMACトークンの発行と使用に必要な情報をエンコードするためのいくつかのクレームを定義していますが、OpenID Connectはまだベアラートークンを使用しています。

ベアラートークンの主な問題は、クライアントの開発者は非常にセキュリティを意識する必要があり、そのセキュリティはTLSにの​​み依存していることです。

多くの人々はこの最後のステートメントを誤解し、OAuth2は本質的に安全でなく、役に立たず、運命にあると結論付けています。さらに悪いことに、彼らはこの種の結論を話し合い、投稿、コメントで盲目的に繰り返し、単に人々を混乱させています。

OAuth2は、一部のユースケースには非常に優れており、他のユースケースには不向きです。一部のセキュリティ原則を十分に理解する必要があります。それもいくつかの妥協が必要です。しかし、それはそこにあり、機能しており、非常に難しい問題を解決します。

MACの使用は標準化されたことはありませんが、ドラフトはかなり良く、簡単に実装できます。今日もいくつかの選択肢があります。

（*）：クライアントがMAC検証を実行しないことを意味します。もちろん、聴衆と他の分野はまだ検証されるべきです。

3
GnP

OAuth WGは、アクセストークンをクライアントのX.509証明書にバインドできるようにする優れたセキュリティ拡張機能を開発しています。クライアントとリソースサーバーで実装するのは比較的簡単で、パブリッククライアントでも機能します。 https://tools.ietf.org/html/draft-ietf-oauth-mtls-

0
Vladimir Dzhuvinov