OpenID、OAuthおよび/またはOAuth 2.0を使用して認証された場合の各リクエストのログイン状態の評価

Question

OpenID、OAuth（Twitter）、OAuth 2.0（Facebook）を含む自分のWebサイトの拡張ログイン/ ）サインインオプション。

ユーザーが正常に認証され、自分のアクセストークンをデータベースに保存し、ユーザーをログイン状態にリンクするクッキーを書き込んだ場合、ユーザーのアクセストークンがまだ有効であることを確認するためのベストプラクティス？私のサイトへのリクエストごとに認証プロバイダを呼び出さなければならないことは、ユーザにとっては遅くなり、他のサイトが何をしているのか想像できません。

私の推測では、現在のブラウザセッションでのみ有効なCookieを保存する必要があります。したがって、ユーザーがブラウザを閉じるとCookieが期限切れになり、次のリクエストで新しいアクセストークンが生成されます新しいクッキーと一致させる）。また、ユーザーが明示的にログアウトすると、クッキーの有効期限が早くなります。

たとえば、ユーザーが自分のサイトをタブで開いていて、別のタブで認証プロバイダを開いてそのサイトからログアウトしても、自分のサイトを参照し続けている場合、技術的にはサードパーティプロバイダを使用してログアウトできるはずですが、私のサイトからはログアウトされません。

「これは本当に問題ではない」シナリオの1つですか、それとも間違った方法ですべてに近づいていますか？

Answer 1

間違いなくサービスプロバイダーはではありません。ではサービスに提供されるすべての要求に対してサービスをpingして欲しいと思います。 Googleの考えでさえ、はのように思えます。 5分ごとにチェックするように何らかのタイムアウトを設定することもできますが、セッションクッキーという考えは理想的です。しかし、はい、あなたが達成しようとしているものに依存します。

これらのサービスを使用してユーザーをログインするだけであれば、ユーザーがログインしていることを確認して自分のセッションまたは永続Cookieを設定するとすぐにアクセストークンを破棄します。アクセストークンは必要ありません。

これらのサービスでユーザーのデータにアクセスする場合は、もちろんアクセストークンを保持してください。しかし、あなたはおそらくユーザがログインしているかどうかという独自の考え方を維持するべきでしょう。私が正しくリコールすれば、これらのアクセストークンは通常（OAuth 1.0aでは）長く存続します。ユーザーは自分のCookieを持っていないか、ログインサービスを介して再度送信しない限り、自分が言っている人です。

Answer 2

ログインの目的でOAuth/OpenIdを使用しているだけであれば、私はあなたがそれについて心配する必要はないと思います。 ユーザーがの（OAuth/OpenIdプロバイダ）ユーザーであると言っている場合、心配する必要があります。

あなたのウェブサイトがTwitterやFacebookとやり取りするつもりなら、それは別の問題ですが、まだそれはかなり解決しています。ユーザーがそこからログアウトしている間にFBと対話しようとすると、FBはユーザーに再度ログインするように指示します。

結論として、私はそれが本当に問題ではないと思います。