OAuth2 Implicit Grant を使用したいのは、単一ページアプリケーション用に提案されているためです。従来のWebセッションを持たないJavaScriptアプリケーションの場合。アプリケーションには、1時間後に期限切れになるアクセストークンしかありません。ユーザーがセッションを実行できる中央認証サービス(CAS)を使用します。
最初は、ユーザーはセッションを持っていません。ユーザーがJSアプリケーションを開始すると、ユーザーエージェントがCASに移動し、資格情報を介して認証されます。認証に成功すると、フラグメント内のアクセストークンを使用してJSアプリケーションにリダイレクトされます。
しばらくすると、アクセストークンは無効になり、アプリケーションには新しいアクセストークンが必要になります。そのため、アプリケーションはユーザーエージェントを再びCASにナビゲートします。問題は、CASは何をすべきかということです。
ユーザーは既にCASでセッションを持っています。このセッションを使用してユーザーを認証することはできますか?この場合、ユーザーは資格情報を再度提供する必要はありません。
中央認証サービスは、ユーザーの資格情報を再度要求する可能性があります。
私の考えでは、ユーザーに1時間に1回資格情報を要求するのは少し奇妙なので、最初の解決策を選びます。しかし、それはOAuth2 RFCに関する新しいアクセストークンを取得する有効な方法でしょうか?
RFCは「The implicit grant [...] relies on the presence of the resource owner
"。最初のソリューションはリソース所有者の存在に依存していないと思います。たとえば、リソース所有者は数時間コンピュータを離れることができますが、JSアプリケーションはまだ実行中です。アクセストークンが無効になった場合、JSアプリケーションセッションを介して自動的に認証され、JSアプリケーションにリダイレクトされるCASに移動するだけで、新しいアクセストークンを取得できます。これは、リソース所有者がいなくても自動的に行われます。
CASは、資格情報を再度要求する場合にのみ、リソース所有者が存在することを確認できます。ただし、30分ごとに資格情報を要求することになります。
これらのオプションが適用されない場合、アクセストークンを更新するために、RFC6749の4.2の図4のステップ(B)をどのように実現できますか?
CASを制御する場合、新しいアクセストークンにアクセスする方法はユーザー次第です。
ユーザーはすでにCASを使用してSPAを承認しているため、セッションがCASで引き続き有効な場合は、資格情報を使用して再認証するように要求する必要はありません。
もちろん、それらがCASで認証されたままでいられる期間は、許容できるリスクレベル次第です。高セキュリティアプリケーションの場合は、セッションタイムアウトを減らすか、アクセストークンの有効期限がCASセッションタイムアウトよりも早く期限切れになるように設定されている理由を自問してみてください。
元の答え:
Refresh Tokens セクションを見てください。
CASで有効なセッションは、ユーザーエージェントが有効な更新トークンを持っていることを意味します。これは、ユーザーのアクセストークンを更新するために必要なものです。
更新トークンは、アクセストークンを取得するために使用される資格情報です。更新トークンは、承認サーバーによってクライアントに発行され、
現在のアクセストークンがあるときに新しいアクセストークンを取得するために使用されます
無効または期限切れ
修正: 更新トークンは暗黙的な付与に対して発行されません 。
認可サーバーは更新トークンを発行してはいけません。
リソース所有者の「存在」は、最初の承認のためにのみ依存しています。
仕様の関連セクション(セクション4.2.1)は次のとおりです。
If the request is valid, the authorization server authenticates the
resource owner and obtains an authorization decision (by asking the
resource owner or by establishing approval via other means).
ユーザーを認証するために、「リソース所有者に質問する」または「他の方法で確立する」のいずれかのオプションが与えられます。前者は通常、ログイン資格情報を意味します。後者は、ssh authからcookieまで、ユーザーの電話番号を呼び出して、Barnes&Barnesの「Fish Heads」を歌って声紋のサンプルを提供するように要求することまで、何でも意味します。
つまり、CASでのセッションの使用は問題なく、仕様の範囲内です。