残念ながら、ログインページをブックマークするユーザーの実際の問題は、クライアントアプリケーションがログインフローを開始する必要があるOIDCによってきれいに処理されません。
これは、ユーザアカウントの作成時にIDSと呼ばれるクライアントアプリケーションに対応するアイデンティティサーバClientId
であるユーザデータテーブルにRegistrationClientId
カラムを追加することで対処しました。クライアントアプリケーションの構成では、我々は、URIのフラグメントを追加するためのカスタムProperties
辞書を使用します。ユーザーがログインするときに
new Client
{
ClientId = "some_client",
ClientName = "Some Client",
ClientUri = "https://localhost:5000",
Properties = new Dictionary<string, string>
{
{ "StartLoginFragment", "/Auth/StartLogin" }
}
// other config omitted
};
、空の戻りURLは、IDSは、クライアントアプリによって呼び出されなかったことを示すので、我々はRegistrationClientId
を使用しますIClientStore
を照会する場合は、とStartLoginFragment
のURIを組み合わせて、結果のURIを使用してユーザーをクライアントアプリケーションにリダイレクトします。
クライアントアプリケーションでは、そのエンドポイントがOIDCサインインフローを開始します。ユーザーはすでにIDSにサインインしているため、クライアントアプリケーションの正しい場所に戻ってきます。コントローラのアクションは、次のようになります。
[HttpGet]
public async Task StartLogin()
{
await acctsvc.SignOutAsync();
await HttpContext.ChallengeAsync("oidc",
new AuthenticationProperties()
{
RedirectUri = "/"
});
}
SignOutAsync
への呼び出しは、ちょうどすべてのクライアントアプリのサインインクッキーがクリーンアップされることを保証します。私たちのカスタムアカウントサービスにはありますが、通常の "Cookie"と "oidc"スキームではHttpContext.SignOutAsync
が実行されます。通常はIDSへのサインアウトコールも発生しますが、その後のChallengeAsync
によるリダイレクトは保留中のサインアウトコールを置き換えます。
アクションがHTTP GET
であるということは理論的にはこのアクションを引き起こす可能性があることを意味します。せいぜい迷惑でしょう。
IDSが単一のクライアントに対してのみ認証を処理する特殊なケースでは、その多くをスキップすることができます。返信URLのないページにある場合は、クライアントアプリケーションstart-loginに送信してください彼らがログインする前にすぐにエンドポイント。
クロムのみですか? – MJK
いいえいいえ、safari、firefox、chrome(iOS)で問題を再現できます。デスクトップブラウザでも。 –
同じ問題を説明している誰かhttps://github.com/aspnet/Security/issues/1069 –