Hi @junji.katto, in addition to our Attack Protection features (which also include Breached Password detection), you should make sure to review your application configuration is Auth0 is correctly configured, specially the following points:
Ensure all the URLs (callback, logout, web orgin and etc) are accurate and don’t include any localhost, 127.0.01 or any wrong URLs
Ensure that all the Grant Types enabled in the application are the correct ones, if you are not using the Grant Type disable it (e.g. client credentials, password, implicit)
Ensure that the connections enabled for the application are correct, by default all the connections might be enabled for the application, you should disable the ones that are not relevant
If you do that during PostLogin actions, the configuration will be effective only next time PostLogin actions execute, not in the same instance of actions. Also doing this is actions can create rate limits issue for your authentication pipeline, so we don’t recommend doing this in Actions.
Why do you need to add them during the authentication process?
Hi @ablimit , it is hard to say without knowing more details about your implementation.
From an Auth0 perspective, an user can be logged out because:
The session is expired;
The session was either revoked or deleted
The session is not valid anymore
But as I’ve mentioned there are many other different factors that can influence why users are being log out. The application might have its own session, the application might use refresh tokens.
If you give some more details about the application, I might be able to give some more information
Hi @ksarun1988 , this approach might work, but it is hard to be 100% sure the session will still exist next time the user click in the link in the Native app.
We will release a new enterprise feature called Native to Web SSO probably by the end of April that will help to have a more consistent way to provide SSO on those cases.
Thanks for coming back to me. I’ve been able to add roles to users, it’s getting the role information that I’m struggling with.
Essentially, I’m just trying to get hold of a user role for RBAC purposes. It’s a B2B SaaS application so using organisations, and I want the lead person from the organisation to be able to use an admin dashboard and invite new users. They can add a role at this point but also have the ability to update roles as they see fit later.
Admin’s obviously get in to the admin dashboard and if you’re not an admin, you don’t get in to that section but can see the rest of the application.
Is the only way to achieve this by obtaining an access token and then making a call to the mgmt api to retrieve the users role? Or is there a way the role can be added to a users profile as a custom or built in claim that can then be obtained in the useUser() call or getSession() call?
None of Google, Facebook, LinkedIn, and many others use public clients (in a browser’s debugging tools, we can find session cookies but no Bearer access token). So, configuring single-page and mobile applications as public clients isn’t something we have to do. And according to an increasing number of recommendations, we shouldn’t do this, even with PKCE. One of the serious sources explaining why is this Spring Security team post (almost 4 years old, but still accurate). Browse to “Final Recommendation” if not feeling like reading the all post.
According to the OpenID spec: “The use of Refresh Tokens is not exclusive to the offline_access use case”.
Provided that a user has an active session on the authorization server, a client should be able to refresh tokens even without the offline_access scope. In that situation, the authorization code flow should run silently too (without prompting the user for credentials) but would use more resources and introduce more latency (get a new authorization code and then exchange it for tokens in another request).
So, refresh token flow is preferable even for “online access”.
I have been using exclusively the OAuth2 BFF pattern for more than two years now. This is how I currently set things:
Duration of the session on the authorization server <= duration of refresh tokens. As seen above, if the session is longer, new tokens can be issued silently using the authorization code flow or a remember-me cookie, but that’s less efficient than the refresh token flow.
In SSO environments, the duration of refresh tokens may depend on the client (some “sensitive” clients use shorter-lived refresh tokens).
As, in the OAuth2 BFF pattern, tokens are stored in the client’s session, this session should last at least as long as the refresh tokens for them to be useful.
At the end of the day, the easiest option is to use the same duration for refresh tokens, the session on the authorization server, and the session on the client. In the case where I have no other choice than to have different durations for clients of the same SSO, I set the authorization server’s session to the shortest of these durations, and, for each client, the same value for the refresh token and BFF session.
If you use our SDKs and don’t use Refresh Tokens, both SPAs will benefit from SSO, you don’t need refresh tokens from that.
Once you terminate the session, the Session is terminated for both SPAs.
If you decide to use Refresh Tokens, they will be independent from each other and revoking or logging out from SPA won’t affect the other. Also, when the session expires, you won’t be able to benefit from SSO.
There are few cases where you can use Refresh Tokens in SPAs, but for the majority of the use cases, using Auth0 Sessions should be enough.
Thanks @nelson.matias ,
So if I understand you correctly, refresh tokens are never bound to the SSO session,
even if they are rotating tokens.
So if we want to have the behavior described, which would be SPA’s effectively sharing a federated session, the we could not use rotating refresh tokens.
What could we use instead?
Would it be using silent authentication token refreshes?
@monish.biswas , I would strongly recommend using Auth0 SDKs the SDKs by default will only use Auth0 Session and everytime they need to renew the access token , they will also renew the session
The answer for all the above is making an call to /authorize with an extra parameter called prompt=none like explained here
Once you call that, you can get new access tokens, Refresh and Keep the SSO session alive and if the session has expired or revoked, you will also know.