User16367418445556258238 (Customer) asked a question.
I have a situation where I have created two different applications.
I have created UserA and assigned to ApplicationA
I have created UserB and assigned to ApplicationB
When I try to log into ApplicationA with UserA I am fine.
I log out and try to log in ApplicationA with UserB and I get access denied
I try again to log into ApplicationA with UserA and now I get access denied
When I look at the system logs in Okta's "Reports/System Log" I see:
OAuth2 access token is granted - UserA
Evaluation of sign-on policy: allowed - UserA
Verify user identity: success - UserA
-but-
User attempted unauthorized access to app - OpenID Connect Client (AppInstance) - for UserB
If I go to a new browser or completely close this one and reopen, I can log into UserA/ApplicationA no problem
Why is OpenID Connect Client trying to use UserB in this situation and how do I rectify this issue?
Hi @User16367418445556258238 (Customer) , Thank you for reaching out to the Okta Community!
I haven't been able to locate any similar reports, but it sounds like there might be something wrong with the logout flow and it not clearing the session thus creating a conflict when you try to log in with the second one. That's why it works as expected when you try with another browser.
Perhaps review the configuration on the logout part:
https://developer.okta.com/docs/reference/api/oidc/#logout
There's also an older post discussing the logout flow, perhaps it will give you a hint as to what might be wrong:
https://support.okta.com/help/s/question/0D51Y00009L8vy2SAB/oidc-application-logout
If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you.
Hope my answer helps!
--------------------------------
Community members help others by clicking Like or Select as Best on responses. Try it today.
I experienced the same problem. The /authorize step, even if denied access, returns cookies that identify the session. Next call to /authorize will prioritize reading the session from the cookies over reading the session in the actual HTTP request. So while the request has information for user B, the cookie says the session is for user A.
Dealing with the cookies solved the issue for us.
I have inherited this issue from Daniel and wanted to add some observations. I just tested and in our scenario, as Daniel originally described, I'm doing the following:
1) Login to ApplicationA with UserB and get access denied
2) Login to ApplicationA with UserA and now get access denied
3) Look for any cookies and clear them but don't see any cookies which are not related to our site (no Okta cookies from /authorize). Cleared anyway whatever I found.
4) Refresh our login page.
5) Try logging into ApplicationA with UserA and still get access denied
6) Login to Okta as my Admin user and find UserB and click the "Clear User Sessions" button on UserB and clear all tokens
If I repeat this test until step 5) but instead of clearing user session in Okta, do a wholesale clear browser cache in the browser, things start working again.
In each case of failure, the callback issues: error=access_denied&error_description=User+is+not+assigned+to+the+client+application.
John Bruggers, can you provide a little more detail on what cookies you were referring to? I don't see any of the cookies from the bad /authorize attempt stored anywhere.
Perhaps I need to always make a logout call back to Okta always in the event of an access denied?
Any additional info/insight is greatly appreciated.
Thanks for any info you can provide.
The cookie issue can be observed using Postman to interact with your own Okta API server.
Okta does provide Postman Collections for an easy set up:
https://developer.okta.com/docs/reference/postman-collections/
Thanks John. I found it under all site data. Much appreciated!!!
John,
As I'm learning more here, I see the cookie and can delete it in the browser and it does take care of the problem. But because it's under a different domain (our Okta custom domain), my application can't delete it. Because we got an access denied we also don't have an ID token to provide to the id_token_hint query param of /oauth2/default/v1/logout Okta call so I'm not sure how to delete the okta site cookie data programmatically.
I'm curious how you dealt with that or what I'm missing?
Thanks.
Steve
In our solution, the back-end was handling interactions with Okta. The HTTP client was configured to not use cookies.
Gotcha. Thanks.
The real problem for us now seems to lie in the fact that (as stated), once a user has authenticated with user name and password, the /authorize endpoint is dropping an HttpOnly cookie named sid (among others). It seems that the sid cookie is the one getting in the way. If I delete this cookie the problem goes away. This is occurring even when the user is not authorized for the specific application.
Because this cookie is originating from Okta via our custom subdomain, we can't delete this with a server side call and certainly not client side because of HttpOnly.
If a user is not authorized for a specific Okta application, why would authorize be setting this cookie?
The callback clearly shows the error so I simply don't understand why this is happening:
https://<our domain>/api/auth/callback?state=f74d99268f98e4fa04014a050b3fd439&error=access_denied&error_description=User+is+not+assigned+to+the+client+application.
Is there any way to prevent /authorize from dropping a sid cookie when a user is not allowed to access the application?
The other challenge here is that I was thinking that perhaps we could perform some sort of non-contextual logout to Okta because /oauth2/default/v1/logout clears the sid cookie. However, that requires an id_token_hint and since authorize failed, we don't have an id_token to supply to that call.