1

私は別のSOスレッドでこれを見つけました:

手順:

  1. ユーザーが OpenID 対応の Web サイトに接続します。
  2. ユーザーが資格情報を入力します。
  3. POST は BASE64 で作成されます (Web サイトからプロバイダーへ)
  4. 回答が作成されます (有効期限が含まれます)
  5. Web サイトは、ユーザーをプロバイダーにリダイレクトしてログインさせます。
  6. ユーザーはパスワードを入力して送信します。
  7. 検証が行われます。
  8. ログイン！

ステップ 6 ～ 8 はどのように保護されていますか? 私の見方では、クライアントはプロバイダーで認証し、結果をサーバーに報告しています。

クライアントが認証結果を偽造するのを止めているのは何ですか?

4

1 に答える 1

2

主に、認証結果はプロバイダーによって暗号で署名されます。他の攻撃から保護する他のセキュリティ対策もあります。

OpenID 2.0 仕様のセクション 11を引用します。

依拠当事者が肯定的なアサーションを受け取った場合、アサーションを受け入れる前に以下を検証する必要があります。

  • 「openid.return_to」の値は、現在のリクエストの URL と一致します (セクション 11.1 ) 。
  • 発見された情報は、アサーションの情報と一致します (セクション 11.2 )
  • 「openid.response_nonce」の同じ値を持つアサーションは、この OP からまだ受け入れられていません (セクション 11.3 ) 。
  • アサーションの署名は有効であり、署名が必要なすべてのフィールドが署名されています (セクション 11.4 ) 。

もちろん、クライアントは偽の認証結果を送信できますが、検証には合格しません。

于 2013-03-24T10:44:59.717 に答える