1

OAuth2 と、トークンが割り当てられたクライアントの検証について質問があります。

仕様によると、機密クライアントの場合、クライアントはトークンなどを要求するときに、たとえば基本認証ヘッダーを使用して認証する必要があります。これは、クライアントが登録され、アクセス トークンを付与できることを確認できることを意味します。トークン リクエストのヘッダーは次のようになります。

 POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

仕様では、トークンが割り当てられると、クライアントはトークンを使用して、次のように認証ヘッダーに渡すことで情報を要求できるとも述べています。

GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

これは問題ありませんが、1 つ以上のクライアント アプリケーション (App1 および App2 と呼びましょう) と、それぞれ Token1 および Token2 を介してアクセスを許可したサーバーがあるとします。認証ヘッダーで送信されるトークンは、割り当てたクライアント アプリケーションから取得されます。

App2 は (どういうわけか) App1 に与えられたトークンを (悪意を持って、またはその他の方法で) 取得できず、それを使用して、独自のトークンの代わりに認証ヘッダーに渡すことでリソースにアクセスできませんか?

リソースに対して行うリクエストで 2 つの認証ヘッダーを送信する必要があります (可能でしょうか)。1 つはベアラー トークンを使用し、もう 1 つはクライアントの資格情報を使用して、サーブがトークンが正しいクライアントからのものであることを確認できるようにしますか?

4

1 に答える 1

2

短い答え: それは今日の標準化された方法では不可能です。

今日の OAuth 2.0 仕様では、探しているプロパティを持たない Bearer トークンが定義されています。これは、それらを提示するクライアントが、そのトークンの正当な所有者であることを証明せずにリソースにアクセスするためです。トークンは、機密 (TLS) チャネルを介してのみ配信および使用されることを意図しているため、間違ったクライアントに到達することはありません。

OAuth 2.0 ワーキング グループでは、OAuth 2.0 のいわゆる「Proof of Possession」拡張機能を定義する作業が進行中です。これにより、クライアントはリクエストに署名できるようになり、受信者はそれを提示する正しいクライアントであることを確認できるようになります。参照: http://www.thread-safe.com/2014/04/oauth-proof-of-possession-drafts.html

OAuth 2.0 仕様の現在のイテレーションは、クライアント実装を非常に簡単に記述できるようにするためだけに、ベアラー トークンを使用して可能な限りシンプルに保たれています。クライアントとリソース サーバーの両方を制御する場合は、所有証明のための独自のカスタム メカニズムを考え出すことができますが、現時点ではそれを行う標準的な方法はありません。

于 2015-04-24T14:23:02.700 に答える