Simple problem, I want to login and out of an app with various users to check different app functionality. App is using Auth0 for user management.
I am calling the /v2/logout url as a part of my flow.
But somehow, after logging out, when I login again the seamless SSO behavior runs and I'm immediately logged in again with no prompts -- it's as if the logout URL was never called.
Only way to get a login prompt again, is to clear my browser cache. Is there an auth0 cookie somewhere I need to delete as well? Or am I missing something? I'm reading the seamless SSO docs but don't see anything beyond calling /v2/logout.
Calling the Auth0 /v2/logout API endpoint will log the user out of Auth0 and optionally the IdP (if you specify federated parameter). It will not log out the user from your Application so you will need to implement that in your application.
Here in the Javascript SPA example, in the setSession() we are storing the Access token(along with its expiry) and the ID token in localStorage. In the logout() function we are then removing these entries. This is logging out from the Application user session. You can optionally redirect to /v2/logout to clear the Auth0 and IdP session as well in this function. That way, when you are checking if user is authenticated, the isAuthenticated() returns false and we force the user log in again.
So turns out, the issue is around redirecting the user as opposed to calling the logout url directly. I was using a separate ajax api call to the logout url. However when I use window.location.replace(logoutUrl), the logout actually happens.
From the auth0 docs:
To force a logout, redirect the user to the following URL:
https://YOUR_AUTH0_DOMAIN/v2/logout
Redirecting the user to this URL clears all single sign-on cookies set by Auth0 for the user.
So a separate call doesn't work -- have to redirect. Which I suppose makes sense -- a separate ajax call doesn't have the user session context.
Related
client type: Spa
grant type: implicit or code(pkce)
As a user, I want to be able to get silently authenticated if I have already logged with my identity provider. If not stay on the client side just like a guest user. And if I want to login to the client I should be able to get authenticated manually through the login page.
This has both manual sign-in and automatic sign-in scenarios. How would you handle such cases in Open ID Connect?
By adding the prompt=none in client settings will silently get a new token if user has a valid session. But if not I want the user to be able to manually authenticate through the login page upon his/her wish.
If I set prompt=none this will never have any user interaction such as authentication.
tags: Silent authentication oidc, automatic login, SSO
It is quite a deep subject, and the flow typically works like this:
CLASSIC OIDC SOLUTION
User is redirected for each SPA
If signed in already at the IDP there is no login prompt
OAuth state is stored in local storage (though it is recommended to only store actual tokens in memory)
When an access token expires (or before) do an iframe token renewal with prompt=none
When a new browser tab is opened do an iframe token renewal to get tokens for that tab - to avoid a full redirect
When the user logs out remove OAuth state from local storage
The most widely used library is OIDC Client which will do a lot of the hard work for you. See also my blog post + code sample for how this looks visually.
PROBLEM AREAS
It is worth being aware also that iframe silent renewal does not work by default in the Safari browser in 2020. Some notes on this here.
Alternatively, you can use signinSilent(). I have used it on my login page ngOnInit (since AuthGuard will anyway redirect the user to login, I thought it will be the perfect place in my scenario).
// login.ts
ngOnInit(): void {
this.authService.signinSilent().then(_ => {}).catch(_ => {});
}
// authService
public signinSilent() {
return this.userManager.signinSilent();
}
signinSilent method will return the user object if user already has a valid session with idp. else it will throw an error, probably login_required.
This is a summary of an issue I filed directly with expo (it ws closed but I have asked for it to be reopened):
This issue happens whether using AuthSession.startAsync,
AppAuth.authAsync or WebBrowser.openAuthSessionAsync on iOS in
local development and published release (expo managed). Haven't tried
on standalone build yet.
Steps to Reproduce
user presses 'sign in' button, (app calls one of the above methods to kick start authentication session with a Salesforce oauth provider)
user enters credentials successfully
app goes through oauth redirects and returns user to our app and we get our access token.
user presses 'sign out' button (app calls revoke endpoint for token, then calls server endpoint to delete any browser cookie sessions for given account reference)
app navigates to sign in screen
user presses 'sign in' again (app calls the same method from above to start the authentication session with Salesforce oauth provider again)
instead of opening the sign in page, the app redirects itself back with an access token as if the user had successfully entered their credentials, even though any cookies/session data the browser stores should be invalid and necessitate a sign in.
Expected Behaviour
steps 1 - 5 are all as expected. Step six should be
app redirects to Salesforce oauth provider sign in page, in unauthenticated state (ie no cookie or session data that was previously stored is still valid)
user is required to re-enter their credentials
oauth flow takes over and redirects the user into the app if the credentials were correct.
Actual Behavior
as per initial steps where the user is not even asked to enter their credentials (step 6):
instead of opening the sign in page, the app redirects itself back with an access token as if the user had successfully entered their credentials, even though any cookies/session data the browser stores should be invalid and necessitate a sign in.
Reproducible Demo
The code is in a private repo so I can't share details of it, but it's a very standard oauth flow, and seeing it's happening in all three of the method calls from the top suggests to me that it may be due to something in the WebBrowser.openAuthSessionAsync implementation. I have seen on the apple developer docs that SFAuthenticationSession has been deprecated in favour of ASWebAuthenticationSession. My understanding is that this (SFAuthenticationSession) is the browser used by expo's WebBrowser and the wrappers mentioned above (AppAuth and AuthSession) for the oauth interactions. I also see that it mentions it's for a one-time login, which perhaps explains why it would hold onto any session data and jump to the conclusion of re-authenticating without directly seeking credentials from the user, but it seems unhelpful to store a cookie without validating it, which is what appears to be the end result.
Notes
Essentially this is making it impossible for a user to sign out of our app, because the system browser, that we don't have control over, is keeping track of their authentication despite the session value no longer being valid against the server.
I've seen other people looking to find ways to clear cookies from the system browser, which may be what this issue relates to, though it doesn't appear to be possible to access the auth session's browser cookies in any way. This comment on a GitHub issue is exactly what I'm experiencing and need to find a solution to.
I would like users to be able to sign out, and then when they sign back in again they should have to enter their credentials again. Does anyone have any thoughts as to how this might be possible?
On iOS, it's now possible to pass in the following config to WebBrowser.openAuthSessionAsync to essentially treat it as incognito and ensure it doesn't retain any cookies. The effect is that the user will have to re-authenticate each time (even if there session is still active). I'm not aware of a similar approach for Android, however.
Code
const browserOptions = {
preferEphemeralSession: true
}
result = await WebBrowser.openAuthSessionAsync(authUrl, redirect, browserOptions)
We are currently implementing keycloak and we are facing an issue that we are not sure what’s the best way to solve it.
We have different webapps making use of the sso and that’s working fine. The problem we have is when we make log in using the sso in one webapp and then we do the same in a different webapp.
Initially this second webapp does not know which user is coming (and it’s not necessary to be logged in to make use of it). When clicking on “login”, it automatically logs in the user (by making a redirection to keycloak and automatically logging the already logged user in the other webapp). This second logging happens “transparently” to the user, since the redirection to keycloak is very fast and it’s not noticeable. This behaviour is not very user friendly.
The question is: Taking into account that this second webapp can’t know upfront which user is accessing the site (unless actively redirecting to keycloak), is it possible to force always the users to log in for a specific keycloak client? By this I mean actually ask the visitor for user/pw even if keycloak knows already them from other keycloak clients.
Thanks in advance!
In the mail listing from keycloak, they gave me a good solution but for version 4:
in admin console, go to Authentication
make a copy of Browser flow
in this new flow, disable or delete Cookie
go to Clients -> (your client) -> Authentication Flow Overrides, change Browser Flow to your new flow, click Save."
Use logout endpoint as a default login button action in your app and redirect uri param use for login page, where you use your specific client (of course you need proper URI encoding):
https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout?redirect_uri=https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/auth?client_id=client_id&redirect_uri=.....&other_params....
=> user will be logged out and then it will be redirected to the login page
I'm trying to implement a way to actually logout from my application that is using the Valence API. I can obviously clear the session on my end, but is there a way through the API to actually log out of the Desire2Learn site as well? I've looked through the docs and didn't see anything.
No, there is currently no route to explicitly log out, or log in. You can, however, use the Valence auth process to generate credentials for a new user. What you need to do in that case is use a browser to interact with the user that doesn't have an open session with the LMS: as long as the LMS thinks that the browser doing the user part of the authentication has an open session, it will pass back the user credentials for that user instead of asking the user to re-authenticate.
Typically an inactive session with the LMS expires after a short time and then the LMS will force the user to re-authenticate if your app initiates the auth process.
I have a Backbone app where we know start to implement the login. Till now I we had no login and the app starts with creating all relevant models and collection on start. Now the API demands a session cookie to response.
What would be the better solution:
having a login.html that forward to the app.html after a successful login
having the login to be part of the Backbone app with an own route
In both solution, how can I prevent that the user sees the login dialog again, just by pressing the back button?
I use the standard way of login handling, a simple login page separated from the application.
/admin/ in this route I have a simple middleware checking for the user session if the user is not authenticated, he is redirected over /admin/login.
Once the user obtains a valid session he can freely go to /admin/ where my application resides. The same apply when you need to authenticate users with some OpenID or OAuth provider.
There is no use in handling authentication in the browser since it's too much simple to handle it in your backend. In fact in my backend I have only three standard routes:
/* accessible routes */
/admin/login
/* protected routes: */
/admin/
/admin/(...)
/admin/logout
For the back button issue, you just need to know if the user already have a valid session token, then redirect/trigger to the right route (beware of redirection loops)