I’m working on a project where there’ll be multiple SPA applications having okta-hosted login. In those projects there’s a kind of requirement that some of the users of one application might not be having access to the other application.
So, when such users are trying to login to the application to which the user is not assigned to I’m able to display the error page with the error message User is not assigned to the client application. by extending the LoginCallback component. Also having links to Okta dashboard and logout so that the user will be able to navigate to dashboard or user can logout of the application.
So far so good, but the issue that I’m facing is that when trying to logout using authService.logout("/"), I’m getting api/v1/sessions/me 404.
What is the reason that I’m getting 404 and also Is there anyway that I can logout the user?
@Nithish Hi, I am not sure if you are having the similar issue here. https://github.com/okta/okta-oidc-js/issues/200. Can you please check if you enabled 3rd party cookies in the browser? Also, it looks like the specific user is not assigned to the application. Do you have the same issue for the user who is assigned to the app?
Can you please check if you enabled 3rd party cookies in the browser?
Yes, I have checked it. For Incognito mode it’s disabled and that’s where I’m facing the error when the user is not assigned to the application.
I have also tried postLogoutRedirectUri as part of <Security> configuration but there also the same issue I have faced that user is still not able to logout. Getting 404 and again user is navigated back to /implicit/callback with the error message User is not assigned to the client application.
Do you have the same issue for the user who is assigned to the app?
Nope, for other users even in Incognito where by default the 3rd party cookies are disabled logout is working as expected.
@Nithish Can you please open a support ticket through an email to support@okta.com with this issue? One of our Developer Support Engineers will take the case and assist you. Let me know if any questions.
@Nithish If the user is encountering the “User is not assigned to the client application,” they were not granted any tokens but they should still have an Okta session created upon logging into Okta.
AuthService.logout() (built on top of AuthJS signOut) uses the /logout endpoint to end the user’s session which requires an idToken to be passed to it. As un-assigned users were unable to be granted ID tokens, the AuthService.logout method will not work to log them out of Okta.
You mentioned that when a GET to /api/v1/sessions/me is called for these users, the response is a 404, right? Is that before or after your application attempts to log them out?
When logging users out of Okta directly (instead of via /logout), you can instead make a DELETE call to /api/v1/sessions/me to end their Okta session – AuthJS has a closeSession() method for making this call. It’s still unclear to me why you would see the GET request returning a 404 (implying the user is not logged in)…
hi @andrea, i have setup an ionic-angular app and I am facing the same issue. I am using a hosted login page to get my users signed in into the application. But i want to restrict users unassigned to application’s group. Is there a way to disable it from okta dashboard and show an error message on okta widget or does it need to be handled programmatically? TIA!
I might be a little confused by your description, but if the users are not assigned to the application, they won’t see it in their Okta dashboard.
As noticed by @Nithish, the error for users not assigned won’t be encountered until primary authentication is successful (user is logged into Okta) and the widget then makes an authorize request, redirecting the user back to your OIDC application. That’s where the error gets surfaced and is the easiest place to ‘handle’ users that are able to log into Okta but are not assigned to the target application.
Because the error wouldn’t be encountered until after primary authentication in the widget has succeeded, I don’t see a way to have this error shown in the widget itself so I would primarily recommend handling this at the callback route.