Auth0 Home Blog Docs

How to use refresh_token in lock v10?

lock-10
auth0-lock
lock

#1

lock v10 documentation does not contain information on how to use the refresh token to keep a user logged in after 1hr.


#2

The Lock Web (v10) library is meant to be used in the client-side components of a web application; since refresh tokens are generally not available to the client-side of a web application due to security reasons (the browser does not provide suitable storage for such long-lived credentials) there’s also no documentation about it.

The recommended approach to keep a user logged in after the expiration of the initially obtained access token is to leverage an existing authenticated session at the identity provider (your Auth0 account) as means to obtain renewed tokens without forcing the user to input their credentials again. This is a process that is available and documented at the Auth0.js (v8) library (the renewAuth method) and that which is usually referred to as silent authentication.

Have in mind that for this method to work, the initial authentication transaction must have been done in a way that an authenticated session is established at the identity provider. When using Lock 10 in the client application itself this highly depends of the exact configuration being used; the recommended method to ensure an authentication session is established is to use the Auth0.js authorize method which redirects to the hosted login page.


#3

A few follow up questions.

Why is that not part of the lock library? Lock is useless without this functionality in single page applications regardless of what the declared “best method” is. And older versions of lock had it.

The renewAuth call requires a “nonce” but the documentation contains no information on what that is or how it relates to the Auth0 payload returned by lock.

It sounds like Auth0 is incompatible with SPAs by design now. it isn’t supported natively and isn’t maintained as such. The angular plugin doesn’t work with webpack, lock doesn’t include renewing… grrr!


#4

A few follow up questions.

Why is that not part of the lock library? Lock is useless without this functionality in single page applications regardless of what the declared “best method” is. And older versions of lock had it.

The renewAuth call requires a “nonce” but the documentation contains no information on what that is or how it relates to the Auth0 payload returned by lock.

It sounds like Auth0 is incompatible with SPAs by design now. it isn’t supported natively and isn’t maintained as such. The angular plugin doesn’t work with webpack, lock doesn’t include renewing… grrr!


#5

The renewAuth methods is meant to be non-interactive so making it available at a lower-level library (Auth0.js) which does not impose a UI could be one explanation for the inclusion at Auth0.js and not in Lock.

IIRC, the nonce is not mandatory and you should be able to call that method without providing it; the nonce would be only pertaining to a request so it does not have any relation to previous requests, independently of the way those previous requests were made.

There is a gap in using Lock embedded in client app alongside API Authorization or OIDC compliance; we are working on that.


#6

We have just encountered the same problem with renewing a login session on SPA web - has any progress been made?

I don’t see renewAuth in the linked documentation for Auth0.js - is it “checkSession”? That seems to indicated only Hosted Login Page is supported, but we have spent a lot of development effort on locally hosting the Lock due to requirements. What can we do to keep users logged in beyond 24 hours?


#7

We have just encountered the same problem with renewing a login session on SPA web - has any progress been made?

I don’t see renewAuth in the linked documentation for Auth0.js - is it “checkSession”? That seems to indicated only Hosted Login Page is supported, but we have spent a lot of development effort on locally hosting the Lock due to requirements. What can we do to keep users logged in beyond 24 hours?


#8

@jmangelo1 thanks for the response – still not totally clear how to move forward refreshing my jwt with Auth0’s Lock.

Do I need to use Auth0.js to renew the token? Is there a method in Lock that I can just use (similar to auth0.logout())?


#9

@jmangelo1 thanks for the response – still not totally clear how to move forward refreshing my jwt with Auth0’s Lock.

Do I need to use Auth0.js to renew the token? Is there a method in Lock that I can just use (similar to auth0.logout())?


#10

We have just encountered the same problem with renewing a login session on SPA web - has any progress been made?

I don’t see renewAuth in the linked documentation for Auth0.js - is it “checkSession”? That seems to indicated only Hosted Login Page is supported, but we have spent a lot of development effort on locally hosting the Lock due to requirements. What can we do to keep users logged in beyond 24 hours?


#11

The renewAuth method was superseded by checkSession which gives similar behavior with reduced complexity so yes, you should use that one instead of renewAuth. In addition, although the recommendation is to make use of a single login page across applications (hosted login page), you should also be able to leverage those two methods if you implement an embedded login approach using: https://auth0.com/docs/cross-origin-authentication


#12

@jmangelo I can’t use Lock without this functionality – do I have to rip out my Lock logic and replace it with Auth0.js??


#13