So I am working to implement a sign with Auth0 where we are using auth0.js WebAuth.login() with email and password against a database to login. This much of it works.
But how do refresh tokens work? Everywhere I look I see that refresh tokens can only be used in instances where the WebAuth.authenticate() is used instead (where Auth0’s hosted login page is used). I am wondering if it is possible to use refreshTokens to get authTokens where login is hosted on our site without any redirecting.
There are lots of resources out there describing the risks of the password grant and why it isn’t recommended. Auth0 isn’t the only one saying it shouldn’t be used in this type of scenario.
I meant, maybe I understood or not, that refresh tokens are part of an Auth0 session, managed on the auth0 servers. But the webAuth.login() with password grant doesn’t run a session on auth0 servers, but is more of an offline session? From the documentation I read, I’m under the impression that refresh tokens only work with sessions started under auth0’s login UX, like webAuth.authorize() where there is a redirect to another login flow.
There is no session cookie that is created with this flow, that is correct.
Do you mean the Universal Login UI ? It’s possible to get a Refresh Token without using the UI. As I pointed out in my original response, you are able to return a Refresh Token with the password grant by passing the offline_access scope and the correct application config in the dashboard.
Now, that doesn’t mean we would recommend using that flow from an untrusted client, but it is certainly possible.
Using these flows (non-rotating refresh token and password grant) outside of a highly trusted application is not recommended. I would recommend using one of Auth0’s SDKs (or quickstarts) and universal login if you aren’t familiar with the risks and nuance of these flows.