Google Contact Data API に 2 つのレッグ OAuth を使用し、リクエストごとにトークンを生成しています。
次回再利用するためにトークンを保存することをお勧めしますか?
また、古いトークンを検出する方法は?
私はパイソンを使用しています。(および Gdata Python クライアント ライブラリ)。
編集:わかりました、トークンは暗号化を使用してクライアント側で生成され、サーバー側から収集されないため、リクエストごとにトークンを生成しても問題ありません。私は正しいですか？つまり、ユーザーのトークンは決して変更されません (共有シークレットを変更しない限り) ですよね?
2 本足の oauth シナリオには、トークンの作成は含まれないと思います。ユーザーがインタラクション (3 番目のレグ) に参加している場合、ユーザーはそのトークンを承認する必要があるため、トークンが必要です。
ユーザーは 2-legged oauth に直接参加していないため、トークン認証はなく、トークンを保存して作成する必要はありません。
基本的に 2-legged oauth は、消費者として、プロバイダーに行うリクエストに CONSUMER 共有シークレット (プロバイダーも知っている) で署名する必要があることを意味します。これにより、プロバイダーはどの消費者がリクエストを行っているかを知ることができますデータを必要としているのが実際にアプリケーションであることを検証する方法。ただし、ユーザー (第 3 レッグ) は参加しないため、プロバイダーはトークンを作成しません。プロバイダーが 2 つのレッグをサポートし、アプリケーションがそのデータを使用することを許可します。
これは、2本足と3本足のプロセスの流れをより詳細に説明できる優れた記事です。
http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iii-security-architecture/
結論として何かを追加するだけです：
2-legged oauth は単なる認証方法です。消費者は、自分の秘密鍵でリクエストに署名することで自分自身を認証します (これにより、どの消費者が実際にリクエストを行っているかが検証されます)。
3-legged oauth は認証と認可です - 消費者は自分の秘密鍵でリクエストに署名することで認証し、認可されていないリクエスト トークンを取得します。これをユーザーが認可する必要があるため、消費者はプロバイダに対して認可されたリクエストを行うことができます。