My situation:
I'm using Duende identity server for authentication in browser extensions and mobile apps using grant type "authorization_code". For authentication, my clients are redirected to our identityserver implementation which is an AspNet core application inspired by the quick start examples of Duende. My clients are "multi-identity" which means that a user can add multiple identities to the clients and switch between identities by a press of a button.
This is all working fine, but...
Signing-in on the identity server should only give the clients access to our backend using access tokens etc, but should not keep the user signed in on the identity server.
Because of the authentication cookies that AspNet core uses, I think the user that has last signed-in stays signed-in whenever he accesses the identity server. This is a potential security issue, but also confusing for the user, because, due to the multi-identity nature of our software the identity that is signed in, might not be the identity that the user is expecting. Therefore, before allowing a user to perform account operations on the identity server, we first sign-out the user, such that the user can then explicitly sign-in under the intended account. This is doable, but not as convenient as it should be.
So my question is,
can we do without such cookies and have the identity server only perform password validation (including redirecting to external login providers), and dealing with oidc (access/identity/reference/refresh) tokens? For account operations, the user signs-in directly on the the identity server via the web browser.
You can force IdentityServer to always ask the user to authenticate, even if he still has a valid session with IdentityServer, but setting the prompt parameter in AddOpenIDConnect to login
See the documentation here https://docs.duendesoftware.com/identityserver/v6/reference/endpoints/authorize/
).AddOpenIdConnect(options =>
{
//...
options.Prompt = "login";
});
Cookies are needed during the authentication handshake, but after that the cookies are not needed. You could also give the IdentityServer sesion cookie a short lifetime.
Typically, in the the client is done, the OpenIDConnect handler asks the cookie handler to do the signin of the user. (OpenIDConnect only handles the challenge part).
If you don't want to use cookies at all, then there is the new BearerToken handler that I blogged about here https://nestenius.se/2023/08/29/bearertoken-the-new-authentication-handler-in-net-8/
Conclusion, you do not need cookies at all after the user is signed in, but somehow you do want to remember the user.