We’re excited to invite you to our next interactive Auth0 Community Ask Me Anything (AMA) session on Wednesday, February 12, 2025! This is your chance to learn how to optimize your use of Auth0 sessions, leverage refresh tokens, and effectively use the Management API to enhance security and streamline your authentication processes.
How It Works
Starting January 28 through February 11, 2025 Auth0 developers, customers, and community members can submit their questions directly in the Auth0 Community. Just hit the “Reply” button on this dedicated thread! Then, on February 12, from 8 am to 10 am PST, our product experts will provide detailed, written answers to all questions submitted during this 2-week period. As a bonus, participants will earn points and a special badge!
What You’ll Learn:
Best practices for managing Auth0 sessions and leveraging the Management API.
How to properly use and rotate Refresh Tokens, including their lifetimes and relationship with session durations.
Advanced features like Continuous Session Protection and how to optimize your implementation.
Key differences between Refresh Tokens and Sessions, and how they work together to maintain secure and seamless user authentication experiences.
Ask Questions here by hitting the reply button below. Be sure to submit your questions from today, January 28, to February 12, 2025.
Nelson Matias is a Group Product Manager leading the Auth0 Sessions and Refresh Tokens team. Over the last 6 years at Okta/Auth0, I’ve had the privilege of working in various roles, including Solution Architect, Principal TAM, and leadership positions. With more than 10 years of experience in Identity and Access Management, I began my career over 20 years ago as a Java Developer, and I’ve continued to grow my expertise in this space.
I wanted to know if I implement @auth0/auth0-acul-js today in my current application (Example: React app with Auth0 React SDK). Do I need to use @auth0/auth0-acul-js with @auth0/auth0-react SDK or just using @auth0/auth0-acul-js I would be able to check isAutheticated and getTokenSilently()?
Also, the documentation of @auth0/auth0-acul-js is not very clear on token management?
If we consider that the use of confidential clients should be preferred over public ones, and also that tokens should be hidden from single-page and mobile applications (prevent them from being exposed to the code of malicious dependencies or stolen from device storage), there is another session to put in the picture: the OAuth2 client session in which the tokens are stored.
Is it planned to include documentation about why the OAuth2 BFF pattern should be preferred to using public clients (like most Auth0 SDKs are doing)? And Also on:
How can the relative lifespans of the refresh token, the authorization server session, and the Oauth2 clients session (confidential clients running on the backend) be tuned?
When and how to “refresh” refresh tokens / keep sessions alive, and what are the consequences of letting each expire?
Can a Back-Channel Logut event be fired when a refresh token or a user session on the authorization server expire?
Is there any solution planned for Session sharing between a Mobile App and a Browser application. We have a scenario where a Mobile App authenticates the user (with a browser based login flow), so a session is also initialized in the phone’s browser. On some pages within the app the user’s need to go to a hyperlink that opens in the browser (i.e. for opening another web application that is also using the Auth0 session). This is currently working as long as the session in the browser is still valid. But as the session expires after the inactivity timeout, the users often have to re-login in the browser window then. Is there anything planned on how to share the app’s session to the browser or to create a new session in the browser by using a valid access or refresh token that would be available in the app?
hi! I’m new to Auth0, and I’m conducting a vulnerability scanning on the web app. Some of the findings are related to vulnerabilities to attacks such as SQL, LDAP, and XPath Authentication Bypass. In addition, it also shows vulnerability to Brute Force attack. I have enabled the Bot Detection, Suspicious IP Throttling, and Brute-Force Protection on the Attack Protection settings. Is there other configuration I’m missing to ensure my web app is not vulnerable to such attacks on the authentication page?
HI.
I’m very new to Auth0 and having a bit of trouble setting up RBAC for a Next.js 15 standard web app. I’ve been able to add roles to users using post login actions but the role is not available in the user object. Reading the docs, it suggests that permissions must be added to the roles but the system won;t allow me to add permissions as there’s no API associated, other than the Auth0 management API.
I have a work around that obtains a users role from the management api which works in dev (localhost) but when I build a container and deploy this functionality doesn’t work.
If you can point me at what I’m missing that would be great.
Please suggest the best way for SSO for the following use cases, Using React native SDK in mobile app and Auth0 universal login. When user login in with auth0.webAuth.authorize and if open link in the browser inside mobile app using ASWebAuthenticationSession , SSO works . Is this correct way or any other better way?.
Using Universal login. When login token session expired in mobile app, Auth0 SDK will retrieve new token, but in the browser inside mobile app(ASWebAuthenticationSession) not sharing the new token ?. It’s asking for login again inside the browser. Is there any approach from mobile app Auth0 SDK to handle or will it handled by Auth0 react native SDK or it has to be handled manually from mobile app to share the session cookies into browser (inside mobile app)
Urgent: Auth0 Setup Failing – Login/Registration Link Broken
Hi everyone,
Newbie here, and honestly, I’m at my wit’s end with this setup. I’m in the final stretch before launch and desperately need help getting Auth0 to work properly.
Here’s the situation:
I tested everything in the Auth0 dev environment, and it seemed fine.
But when I try it on my actual site, the login/register link is broken—it just doesn’t work.
The registration process includes dynamic paywall elements, so it’s not just a basic setup.
I’ve watched countless YouTube tutorials (seriously, overload at this point), but none of them show exactly what I need.
I’d really appreciate a clear, step-by-step guide to setting this up correctly. Apologies if I sound flustered—just feeling the pressure right now.
Has anyone faced this issue before? Any help would be a lifesaver!
@sumansaurav , this is not necessarily related with Sessions and Refresh Tokens but the ACUL SDK is focused primarily on helping devs build screens and submit data to Auth0 server. ACUL is at the most basic level, just a rendering engine for building UL screens. You main app still needs the React SDK to interact with your Auth0 tenant.
Is it planned to include documentation about why the OAuth2 BFF pattern should be preferred to using public clients (like most Auth0 SDKs are doing)?
This is not something we were planning to add in our documentation in the short term, but thanks for the suggestion, I will work with the team internally to add some documentation or blog post around it.
Regarding Public and Private Clients, there are use cases where you have to use public clients such as SPAs and Native Applications.
How can the relative lifespans of the refresh token, the authorization server session, and the Oauth2 clients session (confidential clients running on the backend) be tuned?
I’m not sure I follow your question, but the Refresh Token lifetime and the Authorization Server Session are independent, refresh tokens supposed to offer offline access to application, therefore not being tied to the lifespan of the session.
The backend session might vary depending on your requirements and implementation, which can be similar to the authorization server session or not, again depending of each case. If we give some use case examples, we might be able to work together to understand the best approach on them
When and how to “refresh” refresh tokens / keep sessions alive, and what are the consequences of letting each expire?
For majority of the use case in Web application, you should probably rely on the session. As mentioned before refresh token should be use, mainly, in cases where you need offline access, therefore the user won’t be performing the transaction or for Native applications where you can’t rely on the session. This blog post that talks a bit more about the usage of Refresh Tokens
Can a Back-Channel Logut event be fired when a refresh token or a user session on the authorization server expire?
Back-channel logout is only fired when a session is revoked, more details here
HI @larsf96 , thanks for the question. We have a product feature in our roadmap called Native to Web SSO, which will provide exactly what you are asking.
With that said, this might be release as an Enterprise feature by end of April’25.
