Auth0 user@example.com continues to use the application without being logged out.
When Auth0 user@example.com’s access_token expires the Auth0 session remains valid and the user is able to obtain a new access_token without having to log in again.
Using Rule based account linking solves all of this except that it only works when the Accounts use the same email address.
The process of authenticating the user with Google appears to invalidate the original user’s session which then prevents the original user from continue to use the application after their token expires.
Let me look into this a bit further. In the mean time I would like to address this line:
We suggest that you do not store sensitive information in local storage as it is vulnerable to xss attacks:
I think this would be the result of the SSO cookie for user@example being written over by a new cookie for personal-email@gmail. I can look into this more and get back to you.
I had not realized the token storage recommendation had changed. Our implementation was taken directly from Auth0 example code which stored tokens in local storage. I will definitely take this new info back to my team.
I disabled all of the Social Connections that were using dev keys and am still experiencing the same behavior. I would have been surprised if that was the issue as I was not actually using any of those Social Connections (Google, Twitter, LinkedIn).
I probably should have pointed out that for our scenario we are actually using the Custom Social Connections extension. The connection works correctly with login and account linking it is still just the session that is the issue.
I think you’re right. Your session issues have nothing to do with the fact that your social connections are using dev keys. Only if you were using one of those social connections in the account linking process (as per your example in your original post) would there be a possible impact to the Auth0 session. So I think there’s something else going on here…
Can you check to see if the code in your application that’s performing the refresh of the tokens (which relies on the Auth0 session) is using a specific connection - perhaps even the database connection that the user signed in with when they first launch your SPA?
If so, then here’s what’s happening:
Today, an Auth0 session is essentially bound to a single connection. If you perform another authorization flow and specifically request a different connection than the one the user authenticated with to create the current session, Auth0 is going to prompt the user for authentication. In your use case, this is happening two different ways:
When you want it to, which is when you perform the link to your custom social provider. Here you’re intentionally passing a connection parameter that points to the name of your custom social connection. Auth0 has an existing session, but because you’re using connection it ignores that and attempts authentication against the alternative connection. In the case of your custom social provider, it satisfies this request by redirecting to that provider’s authorization endpoint, which (unless you already have a session there), will most likely send you to their login page. When this authorization flow completes, Auth0 then replaces your old session with a new one (by setting a new cookie) that’s now bound to the connection of the custom social provider.
Some time later, when your SPA decides to refresh its session, (my theory is) you’re passing connection again, but this time with the original connection name, which of course is different from the custom social provider. Again, Auth0 needs to satisfy this request and prompt the user for authentication. And since this is a database connection, it sends them to the login page.
I hope I’m on the right track. Please confirm if you can.