11

REST サーバーをOAuth2で保護し、制御するいくつかのクライアント アプリのクライアント資格情報付与タイプを実装しました。ここで、トークンの寿命を長くする(つまり、期限切れにならないようにする) か、クライアントに頻繁に再認証させる (リフレッシュ トークンの有効期限に応じて) かの決定に直面しています。1 つ目は、キャプチャされたトークンが悪意のある人物によって使用される可能性があることを意味し、2 つ目は、クライアント シークレットが非常に頻繁に公開され、トークンの取得に使用される可能性があることを意味します。

リソースサーバーからクライアントサーバーへの認証でより安全なのはどれですか? 盗難が疑われる場合、トークンとクライアント シークレットの両方が無効になる可能性があります。明らかに、すべての通信はhttps経由で行われます。

現在、クライアント シークレットはトークンよりも強力であると考えているため、この 2 本足のシナリオには長寿命のトークンの方が適しているはずです。(すぐに実装する 3 脚の付与タイプについては、ユーザー セッションとして機能する短命のトークンを優先します)。

ご感想ありがとうございます！

4

1 に答える 1

12

仕様によると、クライアント クレデンシャル フローは、クライアント シークレットが盗まれるリスクを負っていないクライアントに対してのみ許可されます。

クライアント資格証明付与タイプは、機密クライアントのみが使用する必要があります。

したがって、このフローを信頼できないプラットフォーム上のアプリケーションと組み合わせて使用​​している場合は、この決定を再検討する必要があります。

プラットフォームが信頼されているという前提条件により、盗まれたクライアント シークレットについて心配する必要はありません。次に、攻撃者が盗まれたアクセス トークンを使用してプレイできる時間と、再認証のための追加のオーバーヘッド(呼び出しは 1 回だけですが、それでもわずかな遅延) を比較検討して決定を下します。両方の参加者が信頼されており、MITM 攻撃に対して適切なトランスポート層セキュリティを使用している場合、再認証手順自体は、クライアント シークレットの公開に関する問題ではありません。

また、クライアント資格情報フローで更新トークンを使用することはお勧めできません(また、不要でもあります)ことに注意してください。

リフレッシュ トークンを含めるべきではありません。

于 2013-01-15T18:13:10.367 に答える