App Engine (Java)、OpenId (Google サインインなど)、OAuth2 (Facebook サインイン) を使用して、Web アプリの認証部分を実装しています。重要な要件には、「署名を保持する」ことと、データストアへの各ユーザーの安全なアクセスが含まれます。
私の理解では、「署名を保持する」機能を実装するには、サーバー側 (App Engine) で生成された共有シークレットを保存するための Cookie が必要です。また、データストアへのアクセスを保護するために、各 REST API 呼び出しには、API が呼び出されるたびにユーザーを識別するための追加の引数 (共有シークレット) が必要になります。この種のセッション管理は、今でも最新の Web アプリの開発を支配していますか? より一般的な質問は次のとおりです: ステートレスの方向に向かう REST の存在下でのセッション管理は時代遅れですか? ここでいくつかの重要な概念を誤解している可能性があります。関連リソースへのガイダンスとポインターを高く評価します。
OAuth について話すとき、keep-me-signed-in 機能を見る別の方法があります。
アプリが OAuth を使用し、ユーザーが認証と承認を行うと、アプリはAccess tokenとRefresh token.This is basic OAuth ワークフローを取得します。
これで、アプリケーションは、HTTP 呼び出しでアクセス トークンを提供することにより、ユーザーに代わって REST API を呼び出すことができます。通常、アクセス トークンの有効期間は短く、通常は 60 分です。したがって、アプリはそのトークンを使用して 60 分間認証された呼び出しを行うことができます。これは、60 分間署名したままにするのに十分です。
その後どうなりますか？
Facebook、Google などのすべての OAuth サービス プロバイダーは、別の REST API であるトークン交換エンドポイントを提供します。リフレッシュ トークンは、リフレッシュ トークン + アクセス トークンのペアと交換できます。繰り返しになりますが、アプリを使用するときはいつでも、アクセス トークンの有効期限が切れている場合は、トークン交換エンドポイントにアクセスして、新しいアクセス トークンを取得してください。
ユーザーが明示的にサービス プロバイダーの Web サイトにログインし、アプリのアクセス許可を取り消すまで、更新トークンは期限切れになりません。