Closed Bouke closed 9 months ago
AuthenticationType must be unique for each instance of UseCookieAuthentication and should be passed to sign-in to avoid conflicts.
Thanks for your reply. They are unique, however the code I included was incorrect. I've updated the post to clarify that AuthenticationType
is unique and is passed to SignIn
.
Ah, I understand now, but I don't see how you can separate these here.
This was addressed in the ASP.NET Core versions of this library by changing the design of SignIn run the auth handler actions immediately rather than store the values for later.
Properties collections are combine when there are multiple signin calls on the same response. https://github.com/aspnet/AspNetKatana/blob/ab378cfef173dd88c513fc037dec34c6e96b0178/src/Microsoft.Owin/Security/AuthenticationManager.cs#L234-L240
Closing this since it's a known design limitation that would require significant changes to addess.
Let's say I'm using two cookie authentication middleware, like this:
Now I want to set both cookies. The Authentication cookie should only be valid for a limited time, and have a cookie duration of Session. The RememberMe cookie should be valid for 60 days.
If I now sign in both middlewares, e.g. like this:
I would expect this to set two cookies. One with Session lifetime, one with 60 days lifetime. However this is not the case, as both cookies are set with a lifetime of 60 days. I believe this is a result of CookieAuthentication using the shared AuthenticationProperties for storing lifetime, and
Authentication.SignIn
merging those properties. There appears to be no isolation between those properties. I would have to use two separate http responses, one for each Authentication grant.Any suggestions on how to get this working?
The same issue could be observed Asp.Net Identity, where the two-factor cookie does something similar. The problem doesn't surface there, as the authentication grant (cookie) has been set in a prior http response.