32

OAuth2アクセストークンの有効期限が切れる理由について、ここで受け入れられた回答：

  • 多くのプロバイダーは、セキュリティ面で非常に弱いベアラトークンをサポートしています。それらを短命にし、更新を要求することにより、攻撃者が盗まれたトークンを悪用できる時間を制限します。（これはどういう意味ですか？TLSなしで送信を許可することを意味しますか？他に何かありますか？）。
  • 大規模なデプロイメントでは、API呼び出しごとにデータベースルックアップを実行する必要がないため、代わりに、復号化によって検証できる自己エンコードされたアクセストークンを発行します。ただし、これは、これらのトークンを取り消す方法がないため、短時間発行され、更新する必要があることも意味します。
  • 更新トークンにはクライアント認証が必要であり、これによりトークンが強化されます。上記のアクセストークンとは異なり、通常はデータベースルックアップで実装されます。

アクセストークンの暗号化されていない送信をサポートしていないと仮定すると、最初の箇条書きが処理されます。

取り消し可能なデータベースルックアップを実行することに問題がないと仮定すると、完全にランダムなアクセストークンが2番目のトークンを処理します。

モバイルアプリの場合、「登録時に取得したclient_idとclient_secretはアプリケーションのソースコードに埋め込まれているため、クライアント認証を強化することはできません。このコンテキストでは、client_secretは明らかにシークレットとして扱われません。」（Google）。これにより、3番目の懸念がなくなります。

では、このシナリオで有効期間の短いアクセストークンと有効期間の長い更新トークンを分離することの利点は何ですか？有効期限が切れていないアクセストークンを発行し、更新トークンの部分全体を無視することは「大丈夫」ですか？

4

3 に答える 3

41

更新トークンと有効期限が切れていないアクセストークンのセキュリティ上の違いは、認証サーバーへの追加の呼び出しが1つあることです。

攻撃者が有効期限の切れていないアクセストークンにアクセスした場合、攻撃者はリソースサーバーに直接電話をかけ、応答として機密データを取得できます。ここで、彼が更新トークン
を盗んだ場合、最初に認証サーバーを呼び出して、それに応じてアクセストークンを受信する必要があります。次に、リソースサーバーに機密データを問い合わせることができます。

更新トークンを使用して認証サーバーからアクセストークンが要求されるたびに、OAuth 2仕様（少なくとも現時点では最新のドラフト）では、サーバーがクライアントIDを確認し、可能であればトークンにバインドされているかどうかを確認する必要があります。

クライアントシークレットを使用した通常のアプローチでは、開いているプラ​​ットフォームにインストールされているアプリケーションを明確に識別することはできないため、アプリケーションを実行しているプラ​​ットフォームは、これを行うためのメソッドを提供する必要があります。たとえば、GoogleではAndroidアプリケーションに開発者による署名が必要です。したがって、 Google APIコンソールを使用してAndroidアプリケーションのクレデンシャルをリクエストする場合は、アプリケーションの署名に使用した証明書のフィンガープリントを指定し、クライアントIDのみを取得する必要がありますが、応答には秘密はありません。トークンを発行すると、Googleは、アプリケーションが開発者によって自分の名前でトークンを要求することを許可されているかどうかを判断できます。

クライアントIDを確実に確認できない場合は、少なくとも場合によっては、更新トークンが盗まれたことを認識することができます。仕様にはこの例があります：

クライアント認証が不可能な場合、認証サーバーは、更新トークンの不正使用を検出するために他の手段を展開する必要があります。

たとえば、認証サーバーは、アクセストークンの更新応答ごとに新しい更新トークンが発行される更新トークンローテーションを採用できます。以前の更新トークンは無効になりますが、許可サーバーによって保持されます。更新トークンが侵害され、その後攻撃者と正当なクライアントの両方によって使用された場合、そのうちの1つが無効な更新トークンを提示し、認証サーバーに違反を通知します。

于 2012-07-16T22:09:26.143 に答える
6

有効期限が切れていないアクセストークンの最大の問題は、盗まれたトークンを置き換えるメカニズムがないことです。有効期限が切れていないアクセストークンにアクセスできる場合、私は事実上そのシステムのあなたです。トークンの有効期間が短く、有効期限が切れている場合は、盗まれたトークンを置き換えるメカニズムと、トークンをクラックする必要があるウィンドウの制限があります。

パケットをクラックしてトークンを取得するのに3時間かかると仮定しますが、アクセストークンは2時間しか有効ではありません。その後、アカウントに侵入できなくなるまでに、トークンが変更されたため、最初からやり直す必要があります。トークンの有効期限が切れていない場合、私はあなたのアカウントに完全にアクセスでき、トークンを削除して再承認を強制する以外に、トークンを置き換える方法はありません。

于 2012-07-13T16:07:49.467 に答える
0

OAuth2アクセストークンは有効期限が切れている必要はありません（つまり、有効期限が切れますが、それから何年もかかる可能性があります）。

アクセストークンは、リソースサーバーから特定のリソースを取得するために一度使用できます。特に、ユーザーによって承認されたリソースの取得が可能になります。一方、更新トークンを使用すると、繰り返しアクセスできます。したがって、すべてのアクセス間でユーザーの操作を必要とせずに、更新トークンを廃止することはできません。

ただし、一般的に、トークンは、同じデバイス上の他の悪意のあるアプリや、電話に対するMITM攻撃によって盗まれる可能性があります。電話が危険な証明書を信頼するようにできる場合、SSLはMITM対応です。これは、企業が内部ネットワークにアクセスするために必要になる場合があります（自己署名証明書を受け入れる必要があります。これにより、企業ネットワーク上で発生するすべての暗号化トラフィックをMITMに送信できます。したがって、トークンを暗号化して送信すると、途中で盗まれることはありません。危険な。

ベアラートークンは、他の形式のトークン自体よりも弱いものではありません。これは、一連の論文で証明されています（私自身のものを含み、掘り下げることができるときにリンクを投稿します）。ただし、ベアラートークンは彼らが行う仮定が有効である場合に適切です。トークンを秘密に保つことができるという仮定は、一般にベアラトークンの主要な仮定です。これが当てはまらない場合、ベアラトークンはセキュリティプロパティをアサートしません（ただし、一部は保持されます）。OAuth Bearer Tokensで指定されているように、ベアラートークンがどの攻撃を打ち負かす必要があるかを定義するNISTレベル3トークンを参照してください。要するに、無記名トークンはトークンの盗難を打ち負かすことは想定されていません。

ベアラートークンを取り消すことはできません、それは本当です。ただし、通常のアクセスパターンでは、取得直後にアクセストークンを使用するため、現在悪用のケースを考えられない場合でも、悪用の可能性を防ぐために、アクセストークンをかなり迅速に期限切れにする必要があります。トークンが長ければ長いほど、盗まれる可能性が高くなります。更新トークンは、クライアントIDを保護できない場合に、より長い時間枠で繰り返しアクセスできるため、実際には盗まれるのがはるかに危険です。OAuth2は一般的にリソースへのアクセスを提供できるため、たとえば、APIをクライアントに一時的に公開するために使用できます。リフレッシュトークンを使用すると、使い捨てトークンとは対照的に、大幅に多くのダメージを与えることができます。

実際、クライアント認証は、ダウンロード時に各クライアントに異なるキーを与えるなど、さまざまな方法でより安全にすることができます。これにより、1つのデバイスでトークンをリバースエンジニアリングすると、クライアントのすべてのインスタンスのセキュリティが破壊される一般的な攻撃を防ぐことができます。その他の考えられる手法には、OAuthを使用してサーバーでクライアントを検証し、アクセスする認証サーバーでOAuthプロトコルの2回目の実行を実行することが含まれます。これにより、クライアントが定期的にキーを更新し、すべてのクライアントが異なるキーを持つことができるようになります。たとえば、FacebookやGoogleが所有する認証サーバーが使用するシステムに過度の負担をかけることはありません。

モバイルアプリを使用する場合、クライアントを保護するための手順を実行しなくても、ある種の多目的ベアラートークンを使用するよりも、長期間有効な更新トークンの方が安全です。これは、ユーザーがトークンを期限切れにできないためです。更新トークンが盗まれておらず、ユーザーが単にアクセスを取り消すだけの場合は、これを行うことができます。ユーザーが単にアクセスを取り消したい場合でも、多目的ベアラートークンを取り消すことはできません。多目的データベース参照トークンは明らかに取り消すことができますが、これはプロトコルが設計されているものではないため、OAuthで実行されたセキュリティ分析はこのハイブリッドシステムのセキュリティについて何も述べていません。

結論として、更新トークンとデータベーストークンを使用することをお勧めします。これは、最も安全である可能性が高いためです。クライアントを保護するために何かできることはボーナスですが、これが保護する状況は最小限です。クライアントを保護したい場合は、Google認証システムであるソフトトークンを検討してください。これは、非常に賢い人々による分析に耐えてきた堅実な実装です。

于 2012-07-19T13:44:38.660 に答える