-
Notifications
You must be signed in to change notification settings - Fork 597
Flow for authenticated but unauthorized users with OIDC is broken (infinite redirect) #667
Comments
Ah, forbidden only kicks in when using cookies. @HaoK |
I think OIDC Challenge needs to check Authenticated(SignInScheme), and if true, call Forbid(SignInScheme). |
Note all the redirecting auth providers could have this issue if used stand-alone. They could all use the same fix. |
Backlog for now. |
Is this still for backlog? Any workarounds? |
Sorry, I'm confused, Regards |
@Mendallas we made internal changes for 1.0 that should address this (#823). You shouldn't have to make any changes yourself. You can try the pre-release packages on myget.org or wait for 1.0 to release. |
For now if you disable AutomaticChallenge on the OIDC MW, then it will fall thru to the cookie middleware and get the desired AccessDeniedPath rendering. |
The live.asp.net web site is configured to authenticate with OIDC (Azure AD) only (as emitted by the template during File -> New). The
AdminController
is configured to require authorization with a policy "Admin", which basically just asserts that the user is signed in with one of three usernames.The issue is that anybody in the Azure AD org (microsoft.com) can sign-in to the site (authenticate), but when they try to access the protected resource (/admin) the policy fails and they're redirected back to Azure to sign-in. As they're already signed in, Azure redirects back to the originally requested resource, which fails the policy, and the loop continues forever.
The desired flow would appear to be that in the case a user is authenticated but not authorized for a resource when using OIDC, a "Forbidden" page is shown (as configured by the app, e.g. /account/forbidden) with a suitable message and a button that enables the user to sign-in as another user. The button would basically sign them out, then redirect them back to the originally requested resource, which would start the proper authentication flow again.
@Tratcher @blowdart @vibronet
The text was updated successfully, but these errors were encountered: