Is it possible to use Auth0 for long-term web authentication?

[pimterry]

Is there any suggested way to use Auth0 for long-term web authentication? I’ve seen various other threads suggesting that it’s impossible to keep a user logged in if they don’t use your web app for more than 3 days, and even if they use it every day, it’s impossible to keep them more logged in for more than 30 days.

Is this accurate? It does seem reasonable as a default, but it’s a very harsh hard limit. I can think of lots of popular web applications that keep me logged in more or less indefinitely (certainly for more than 3 days inactive), and I suspect many users assume this behaviour by default. More practically, indefinite authentication with manual revocation is a strict requirement for my current project.

For context, the only data I store associated with users is their email & current subscription status. Even in a browser, I think the chance of a refresh token being leaked is very low, and the damage if that does happen is minimal (other than the leak of their email address, it’s entirely to my own business: if user B steals a token then they can use user A’s subscription). As a hard requirement though, I do need to be able to confirm users’ subscription status reliably without asking them to log in every week, and I really don’t want to have to build my own authentication infrastructure to do so.

Is there any way (even if normally strongly discouraged) to use refresh tokens on the web, so I can work around this?

[pimterry]

Found it! You can indeed work around this, and the result actually works very nicely:

• Disable ‘OIDC Conformant’ in ‘Advanced Options’ → ‘OAuth’ for your application
• Authenticate with a scope parameter including offline_access in the UI, e.g. with Lock v11:

const lock = new Auth0Lock('...', '...', {
    ...
    auth: {
        params: { scope: 'openid email offline_access' },
    }
}

After authenticating, the auth result in authenticated events from the lock now includes refreshToken, which you should be able to use with Refresh Tokens to refresh. In my case, I’m using auth0-js and doing:

const client = new Auth0.Authentication({
    clientID: '...',
    domain: '...'
});
client.oauthToken({
    refreshToken: authResult.refreshToken, // from the authentication event
    grantType: 'refresh_token'
}, (error, result) => {
    result.accessToken // Fresh refreshed access token
});

I’m sure this is discouraged, and I do agree that if you’re protecting sensitive data or operations, you should ensure users reauthenticate frequently. I definitely don’t agree that every application is doing that though, and being able to opt-out of that and take responsibility for session expiry myself is very useful to me.

The refresh step here is more or less verbatim from the latest react native SDK, so should keep working for as long that’s supported. The initial login step to get that refresh token is that part that depends on non-OIDC behaviour (specifically: refresh tokens must be allowed for implicit grants), so might stop working if that is removed in future. It doesn’t sound like that’s happening any time soon though, and the current docs say this’ll be available ‘until further notice’. I’d like to find an alternative that doesn’t require this, but it seems that’s not currently available.

It’d be interesting to hear thoughts from anybody at Auth0 if there’s any more specific info on when that might happen, or whether there’s any other major caveats to the above.