Renewal of tokens in a SPA

Help
, ,
1

I have some questions related to renewing token in a single-page application that I hope someone can clarify for me.

1. Don’t use refresh tokens?
I’ve read that we shouldn’t use refresh tokens in SPAs, as it doesn’t fit with the authentication flow and because the tokens are more sensitive than what can usually be handled in a SPA (see restrictions section in Refresh Tokens). It would be nice to get it confirmed that this is correctly read and that we should under no circumstances use refresh tokens in our SPA.

2. Use silent authentication?
The referenced section on refresh tokens says that we should use Silent Authentication (Configure Silent Authentication). This page mentions SSO and multiple apps. Is this because Auth0 will have a “login session” and that is what is being validated. I imagine that since we don’t have a refresh token, we are redirecting the user to Auth0 who may use cookies and other checks to verify that it is okay to send a new token. What are the limitations here, e.g. how long after our token expires can we actually renew; do we need to setup SSO in the dashboard and set some timeout?

3. Use renewAuth in auth0.js?
The referenced documentation of silent authentication ends up saying that for single-page applications
we can use the renewAuth method from auth0.js to do the request in a hidden IFRAME. In the GitHub README (GitHub - auth0/auth0.js: Auth0 headless browser sdk) it says about renewAuth that “the user must have an active SSO session at Auth0 by having logged in through the hosted login page of your Auth0 domain.” And from the site (Auth0.js v9 Reference) it also mentions that “[t]he renewAuth method allows you to acquire a new token from Auth0 for a user who is already authenticated against the hosted login page for your domain”. Is it actually required to use the hosted login pages for this? I ask because we need to embed it in our app and need more customizations than Lock provides last time I checked. Also, we tried it out with our own login page and the renewal still seemed to work, but we may be fooled by something.

4. Redirect and hash on URL rather than just a response?
While implementing the renewal, we were wondering why we need to navigate the browser to the Auth0 URL (and then have all the implications of using a hidden IFRAME, parsing the hash and posting the result to the parent)? Is it not possible to make a request from JavaScript to Auth0 and then get back a response in JSON with the tokens? Or is the browser behaving differently in these scenarios, for instance in regards to cookies, CORS or something?

This turned out rather long, but I hope that someone can help clarify the renewal of tokens in a SPA for us.

Thanks in advance,

Morten

2

@mo , I agree we would prefer if it’s not a redirect too.

But looks like most of the Identity as a Service solutions have implemented implicit grant with a redirect & recommend using a hidden iFrame to parse the access token.

So there might be a good reason why it has to be a redirect & not a simple request-response pair.

References:

https://github.com/IdentityServer/IdentityServer3/issues/127

3

Thanks eatfitdev for the clarification. It makes good sense if the other identity providers, which we can use through Auth0, requires redirection. In this way, Auth0 can hide the different ways in which the identity providers work without involving us and just expose the tokens at the end of the redirections in a uniform way.

Do you know what the quotes about SSO session and hosted login pages means? We are not using the hosted login pages, but the renewal seems to work. I’m just worried we are missing something or that it will not continue to work.