私はOpenID Connectハイブリッドフローに取り組んでいます。基本的に、私の場合の応答タイプは次のとおりです。コードid_token問題:id_tokenを使用してログインすると、ユーザーのセッションを持続できないようです。
.Net Coreの組み込みOpenID Connect認証ハンドラーとCookiesハンドラーを使用してアプリをビルドしました。ただし、CookieはセッションCookieであるため、ブラウザーが閉じられると期限切れになります。この場合、ユーザーはログアウトされ、ブラウザーを開いたときに再度ログインする必要があります。そのため、承認サーバーから更新トークンを要求しているにもかかわらず、更新トークンを使用していないと思いました。だから、それらすべてを支配するための質問:ブラウザーにユーザーのログインを維持するには、ユーザーは一度だけログインする必要がありますか?私はCookieに有効期限があり、通常のセッションCookieではないことを理解しています。また、更新トークンを使用して舞台裏でユーザーを再認証し、その過程で新しいCookieを生成する必要があることも理解しています。しかし、私の考えは正しいですか?はいの場合、それを行う方法は?そうでない場合、何が問題でしたか?
更新:セッションCookieが期限切れになる問題を解決しましたが、ログインに使用した認証チャレンジに「IsPersistent」プロパティを追加し、残りはOpenID Connect認証ハンドラーが処理しました。ただし、Cookieは、id_tokenの期間である60分しか持続しません。したがって、更新トークンを使用して新しいトークンを要求できないという問題がまだ残っていますか?
私は最近これを自分で行いましたが、これは主にコンポーネントの制御を制限する拡張メソッドのセットアップメソッドの制限のため、少々苦痛でした。
私が設定したのは、Cookie、JWT、OpenIdConnect認証でした。 cookie authで、イベントをJWTまたはOpenId authに転送します
.AddCookie(options =>
{
options.ForwardAuthenticate = JwtBearerDefaults.AuthenticationScheme;
options.ForwardChallenge = OpenIdConnectDefaults.AuthenticationScheme;
options.Events = new CookieAuthenticationEvents()
{
OnRedirectToAccessDenied = async ctx =>
{
ctx.Response.StatusCode = 401;
},
};
})
JWT認証で、独自のCookieを確認します。
options.Events = new JwtBearerEvents()
{
OnMessageReceived = async ctx =>
{
//get the token from the cookie rather than the header
var token = ctx.HttpContext.Request.Cookies["access_token"];
ctx.Token = token;
},
};
OpenId authでCookieを設定します
ctx.Response.Cookies.Append("access_token", tokenResponse.AccessToken);
ユーザーのログインを維持するために更新トークンを使用しないでください。更新トークンは、オフラインアクセス、つまりユーザーがまったくいない場所で処理されるバックグラウンド用です。
この状況を処理する正しい方法は、id_tokenの有効期限が切れたら、openidプロバイダーに対してユーザーを再認証することです。 openidプロバイダーは、ログインしているユーザーを(たとえば、永続的なcookieを介して)覚えておく必要があり、ユーザーを再認証することなく、すぐにアプリケーションにリダイレクトします。ユーザーが注意を払っている場合は、いくつかのリダイレクトが前後に表示されますが、パスワードを再入力する必要はありません。
あなたがopenidプロバイダーの作者であるなら、あなたはこれをスムーズに機能させるためにクッキー/セッション期間に注意する必要があります。 openidプロバイダーでローリングセッションを使用する場合、id_tokenの有効期限が十分に短いことを確認して、openidプロバイダーのセッションCookieが期限切れになる前にユーザーが再認証されるようにします。
Openidプロバイダーが毎回再認証する場合(つまり、どの形式のセッションもサポートしていない場合)、最善の策は、id_tokenの有効期限を完全に無視することです。