0

OAuth 1.0a で保護されたリソースを処理する方法を知る必要があります。公式ドキュメントを読み、いくつかの実装を見てきましたが、明確にする必要がある点がいくつかあります。

1) この時点で、コンシューマーはユーザーにリンクされた承認済みのアクセス トークンを持ち、プロバイダー サーバーはそれを検証します。

  • アクセス トークンが無効な場合はどうなりますか?
  • Provider サーバーはどのようなステータス コードを発行しますか?
  • これが発生した場合、消費者サーバーはユーザーを別のトークンを承認できる画面にリダイレクトする必要がありますか?

2) アクセス トークンの検証が正しければ、コンシューマとプロバイダは情報を交換します。たとえば、コンシューマーはユーザーの電子メール アドレスを尋ね、プロバイダーはそれを提供します。

  • この情報を交換するには、どのプロトコルを使用する必要がありますか? （ジョン？）
  • この情報は、応答の本文に入れるべきですか、それとも別の場所に入れるべきですか?

3) 提供されたアクセス トークンと保護された情報が消費者サーバーによって永続化される場合は、標準に従います。

ありがとう

4

1 に答える 1

1

おそらく公式ドキュメントをリンクしているはずです。いずれにせよ、ここにあなたの質問に対する簡単な回答があります。

  1. この時点で、コンシューマーは承認済みのアクセス トークンをユーザーにリンクし、プロバイダー サーバーはそれを検証します。

アクセス トークンが無効な場合はどうなりますか? Provider サーバーはどのようなステータス コードを発行しますか? これが発生した場合、消費者サーバーはユーザーを別のトークンを承認できる画面にリダイレクトする必要がありますか?

RFC 5849に従って、提供されたトークンのいずれかが無効な場合、プロバイダーは 401 (未承認) ステータス コードを返す必要があります。

サーバーは、無効なクライアント資格情報、無効または期限切れのトークン、無効な署名、または無効または使用されたノンスを含むリクエストを受信した場合、401 (Unauthorized) ステータス コードを返す必要があります。

  1. アクセス トークンの検証が正しければ、コンシューマとプロバイダは情報を交換します。たとえば、コンシューマーはユーザーの電子メール アドレスを尋ね、プロバイダーはそれを提供します。

この情報を交換するには、どのプロトコルを使用する必要がありますか? (Json?) この情報は、応答の本文に入れるべきですか、それとも別の場所に入れるべきですか?

彼らがそうあるべきだったという用語はcan、そうではありませんwill。この仕様では、認証の完了後にプロバイダーとリクエスター間で送信する必要がある特定の情報を義務付けていません。この決定は、完全にアプリケーション プロバイダー次第です。

  1. 標準に従って、提供されたアクセス トークンと保護された情報がコンシューマー サーバーによって永続化される必要があります。

繰り返しになりますが、仕様によって義務付けられている要件はありません。ただし、プロバイダーから取得したアクセス トークンを保存するのが一般的です。私は弁護士 (IANAL) ではありませんが、プロバイダーから取得したデータを第三者のシステムに保存すると、法律に違反する可能性があることに注意してください。

于 2013-01-23T03:56:52.187 に答える