私たちの API を使用してウェブサイトを強化している多くのクライアントがいます。
OAuth を使用して認証済みの API 呼び出しを行うことについて、職場で会話を始めました。2 本足と 3 本足のフローの両方があります。
3-legged フローについては、アクセス トークンとシークレットを格納する方法についてまだ合意に達していません。
この問題に対する一般的なアプローチは、クライアントにアクセス トークンとシークレットを独自の DB に保存させることですが、クライアントはコードの変更や実装の問題に対処したくないため、これは問題外です。
私たちが検討している他のオプション:
1) アクセストークンとシークレットを Cookie に保存する
2) それらをセッションに保存します。
これらのどちらかが良いアイデアかどうかはわかりません。誰か提案はありますか？
ありがとうございました。
典型的な「サービス プロバイダー」、「コンシューマー」、および「ユーザー」タイプのセットアップについて話していると思います。コンシューマー (クライアント) が変更を拒否した場合、three-legged oAuth を実装できるかどうかはわかりません。
セッションと Cookie はトークンを保存するために機能しますが、問題は、それらを保存する必要があるのはコンシューマー (クライアント) であり、あなたではありません。API への呼び出しはバックエンドで発生しているため、そのスコープ内で使用できる実際のセッションや Cookie はありません。JavaScript 呼び出しのみを行っている場合、おそらくそれは機能しますが、通常は、クロスドメイン スクリプティングの問題が発生しないように、プロキシ経由で呼び出しが行われます。
どちらの場合でも、トークンがセッションまたは Cookie に保存されている場合、それらは「一時的な」キーになり、ユーザーはセッションまたは Cookie の有効期限が切れたときに再認証する必要があります。しかし、ユーザーが再認証を気にしない限り、oAuth の仕様に問題はありません。
Jason が述べたように、認証に必要なトークンを保存しない場合、消費者アプリケーションが認証済みのリクエストを作成することはできません。必要な方法で保存できますが、これは方程式の必要な部分です。ファイルシステム、memcache、データベース、メモリなどです。
これらを保存するために Cookie を使用する唯一の方法は、消費者アプリケーションがこれらのトークン資格情報をユーザーのブラウザーで Cookie として設定し、ユーザーが要求ごとにそれらを消費者に送り返すことです。消費者アプリケーションは、これを処理するためにコードを変更する必要があります。次に、トークンとトークンの秘密鍵がネットとユーザーのブラウザーを重複して飛び回り、ユーザー自身がハッキングを行うことを決定した場合、セキュリティ ホールになる可能性があります。
3-legged oauth を実装したときも同じ問題がありました。アプリケーションをGoogle App Engineでオンラインにし、アクセス トークンの保存に Google DataStore を使用しました。
ただし、データの保存とクエリのスローについては、ここでクォータが言及されています。Google App Engine を使用する際の唯一の制限です。
について 1) アクセストークンとシークレットを Cookie に保存する
クライアントがインターネット カフェにいるとします。クライアントが Cookie を消去せず、次の人がこの情報をコピーした後はどうなりますか?
DBまたはPHPセッションに行きます