SPA + Embedded Login + Token Refresh Strategy?

Help
1

Hi there,

I’ve implemented an Angular SPA with Lock.js as an embedded Login Solution using Auth0 with a custom Domain.

After running Lock.show and redirecting on my index.html I’m using the following code to save the Tokens in LocalStorage:

lock.on("authenticated", function (authResult) {
            // Use the token in authResult to getUserInfo() and save it to localStorage
            lock.getUserInfo(authResult.accessToken, function (error, profile) {
                if (error) {
                    // Handle error
                    return;
                }
                document.getElementById('nick').textContent = profile.nickname;
                //this stores id_token, access_token and expiry_date in localstorage
                saveAuthResult(authResult);
                this.checkSession();
            });
        });

When re-entering the website or by a scheduled Timeout I check the expiry_date to determine the validity of the token client-wise. However, what option do I have to renew the JWT tokens (ID and Access token) once they’re expired? When using Lock.show again the user would have to re-login every two hours ( current expiry limit of my JWT). If I use the check_session function (Silent Auth) I’m faced with “error: login_required” ( also when my JWT is still valid).

What is the recommended strategy in this case to renew my tokens?

2

(EDIT: added the fourth possibility, dev keys)

If checkSession is returning login_required this means that Auth0 could not find a valid session for the user. This could be because:

  • A session was never created. When instantiating Lock, are you using the sso: false option? Doing so instructs Lock to use the token endpoint directly, without setting a session for the user.
  • The session has expired. Check the session duration in the tenant Advanced Settings.
  • The session cookie was not included in the request. This could happen if you are not using custom domains and the browser blocks the third-party cookie. Safari actively blocks this.
  • Using social connections with the default developer keys won’t set an SSO session (see Test Social Connections with Auth0 Developer Keys). Make sure you configure your own keys.

Do any of these help explain the situation?

3

thanks @nicolas_sabena. 2. and 3. I could exclude by double-checking my Auth0 Dashboard settings. I tried setting SSO to true explicitly ( wasnt set before):

These are the auth settings for Lock:

var configuration = {
    auth: {
        sso: true,
        domain: "auth.mycustomdomain.com",
        responseType: 'token id_token',
        scope: 'openid user_id profile fullname picture user_metadat  https://my-custom-domain.com/roles https://my-custom-domain.com/purchased_courses expires_in',
    },
    loginCallback:"mycustomdomain.com/app"
};

Still check_session gives me “login_required” error each time I check.

Edit: Is there a way to check if a session is set using Chrome debugger tools ? Fact is: LocalStorage shows the data I stored. Session Storage for the domain is empty ( no entries). Does that mean that there is no session existing ? What else could be reasons?

4

Are you testing this with a social connection? If so, have you set up your own keys, or are you using Auth0’s developer keys? Dev keys have many limitations, one of them being that you don’t get a valid SSO session.

If you have set up your own keys, please record a .HAR file as instructed in Generate and Analyze HAR Files and attach it here (remember to obscure any passwords used).
Make sure to include the first login and the subsequent refresh and silent token retrieval attempt.

Is there a way to check if a session is set using Chrome debugger tools ? Fact is: LocalStorage shows the data I stored. Session Storage for the domain is empty ( no entries). Does that mean that there is no session existing ? What else could be reasons?

Whatever is in localStorage belongs to the application itself (the Angular SPA). The Auth0 session is stored on the Auth0 servers, with a reference to it in the session cookie (called auth0, under your Auth0 domain).
If cookies are working, you should see an auth0 cookie sent with every request to your Auth0 domain. But that’s a reference to the session, nothing guarantees that it will match an existing session on the server (although it should under normal circumstances).