-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cookie compatibility between OWIN and Microsoft.AspNetCore.Authentication #435
Comments
50-80 claims is a lot to try to fit into a cookie.
Unfortunately those are required, they're all referenced indirectly from the interop code you're adding. |
I couldn't find a working example for ITicketStore for ASP.NET and ASP.NET Core so I've opted to store my access rights in Session (HttpContext.Current.Session) for my ASP.NET applications and in MemoryCache (Microsoft.Extensions.Caching.Memory) for my Blazor applications. Does this seem like a good approach?
Would you recommend updating them to the latest version or keeping them on a specific version? I'm asking because a lot of these nugets seem to be updated for .NET 6 and I'm thinking the Microsoft.Owin.Security.Interop was created with a specific version. |
Don't use Session for auth data, it doesn't have the same lifetime and could leak after signout. You can use MemoryCache in both apps. You can update to the latest patch version, but don't update to 6.0, there are breaking changes across major versions. |
Okay thanks! Any suggestions for the lifespan settings of the MemoryCache? (I have load balanced websites as well, does that have any impact?) Current settings are as follows
What version would you suggest upgrading to? 2.x,, 3.x, 5.x, 6.x? Considering I am on .NET Framework 4.7.2 |
Oh, for load balanced sites you'd need to use IDistributedCache instead, and that will have its own lifetime settings. It's mainly a tradeoff of how much cache space you're willing to use vs how long you're willing to let people sit idle and stay signed in. Stick with 2.1 if you're on .NET Framework, I think that's the last supported version of Microsoft.Owin.Security.Interop and you want the dependencies to be at the same major version. |
So just to confirm, I have these nuggets at the following versions (not all had a 2.1 release).
Does that seem okay? |
I think you'll want the 4.x versions for the System dependencies, but if it works then I wouldn't sweat it too much. |
Thanks again! I have another follow-up question. I figured out why my cookie is so large and it's because I have set |
You only need SaveTokens if you're going to make API calls on behalf of the user using those tokens. Even then, you can store those tokens in a local user database, they don't need to be in the cookie. |
Excellent, thanks a lot for all the help! |
@Tratcher I'm sorry for re-opening this, but after having disabled SaveTokens our Logout does not work any more. I get the exception "The endSession endpoint requires an id_token_hint parameter". Logout Methods
When I try to get the IdToken now it is indeed null. When setting SaveTokens=true it does indeed return the token once again.
I'm assuming I will have to save the IdToken elsewhere to be able to handle this (like in the database as you said), or is there another way around this? This IdToken is quite large. Can you set the IdToken Manually in the SignOut method? Where would I get the id_token from to store it somewhere? |
The default signout code doesn't set id_token_hint, where were you setting it? AspNetKatana/src/Microsoft.Owin.Security.OpenIdConnect/OpenidConnectAuthenticationHandler.cs Lines 80 to 84 in b32c437
|
So I figured out this works with our ASP.NET (OWIN) Applications but not our ASP.NET Core Applications. I'm guessing they have a different implementation? |
Ah, AspNetCore does set the hint, though that shouldn't matter if the token isn't stored. Do you have a trace of the signout request? Is id_token_hint present but empty? Otherwise I don't know why the remote provider would complain about the missing hint for core and not katana. |
This is the signout request url? We are using ForgeRock and in their documentation the id_token_hint is required apparently. I do wonder why it does work in OWIN, it might be because after the signout we do a redirect.
|
Oh, yeah, you're skipping the OIDC remote logout there, you're only logging out locally. |
What would be the correct way to logout fully there, or is that not an issue? Maybe that could be a solution for the ASP.NET Core Application as well? |
Instead of adding your own redirect to OpenIdRedirectPostLogout, you pass that value to Signout in the AuthenticationProperties.RedirectUri. AspNetKatana/src/Microsoft.Owin.Security.OpenIdConnect/OpenidConnectAuthenticationHandler.cs Lines 89 to 93 in b32c437
You can also set it on the options. AspNetKatana/src/Microsoft.Owin.Security.OpenIdConnect/OpenidConnectAuthenticationHandler.cs Lines 94 to 97 in b32c437
That said, you'll be back in the same position of needing the id token hint, storing the token in a database, and adding it to the signout in the events. |
Thanks! That makes sense. |
You'd need to hook into the events and update the OpenIdConnectMessage. AspNetKatana/src/Microsoft.Owin.Security.OpenIdConnect/OpenIdConnectAuthenticationNotifications.cs Line 48 in b32c437
Storing and retrieving the token elsewhere is up to you. |
I've tried to do this in the following ways but without success:
When I send the user to the page
This is also not the case for ASP.NET (Owin) applications right? That does not have an OnRedirectToIdentityProviderForSignOut . |
Owin/Katana has a shared RedirectToIdentityProvider and you need to check the message type:
You didn't name your auth provider "oidc", it's using the default name OpenIdConnectAuthenticationDefaults.AuthenticationType "OpenIdConnect". |
Thank you! I'm almost there I think, I get redirected now, the token is filled in but I get the error "Not an RSA algorithm." from our identityprovider.
|
Was that the right token? |
It was not, my apologies! And thank you for all the help. :) |
Hello
I have applications both running on ASP.NET MVC (4.7.2) and ASP.NET Core (Blazor, 5.0). I secure these with OpenIdConnect.
I would like the cookie to be compatible between these applications, as it currently stands these both create their own cookie and requires re-authentication.
Example: I connect to portal.domain.com (ASP.NET MVC 4.7.2), this requires an authentication flow and creates a cookie. I click through to application.portal.domain.com (ASP.NET Core (Blazor, 5.0) and this requires another authentication flow and creates a second cookie.
However if I click through to application2.portal.domain.com (ASP.NET MVC 4.7.2) (from portal.domain.com) this does not require a second authentication flow and re-uses the original cookie (as it should).
Are there specific settings that need to be adjusted so these cookies become compatible?
ASP.NET Authentication Code (Startup file)
ASP.NET Core Authentication Code (Startup file)
Thanks in advance
The text was updated successfully, but these errors were encountered: