Hi, I am looking to have my backend server get a refresh token from google. Usually, the flow is as follows, the frontend app requests google’s oauth server with an access_type=offline which then returns an authorization code to the frontend app. this code is sent to my server where it can be exchanged for an access_token and refresh_token from google. This allows me to make api requests to google on behalf of the user when they are offline. However, I have the following configuration for Auth0Lock
auth {
redirectUri: AUTH_CONFIG.callbackURL,
responseType: 'token id_token',
params: {
audience: `https://${AUTH_CONFIG.domain}/userinfo`,
access_type: "offline",
approval_prompt: 'force',
scope: 'openid email profile' // Learn about scopes: https://auth0.com/docs/scopes
}
}
Yet, when I get back a response from auth0, i do not see an authorization code from google or a way of getting this information. Please help, I have literally googled everything!
The flow you initially described in your question is applicable when interacting directly with Google. When going through Auth0, but while still making use of Google social authentication, the process is slightly different; you still need to do the access_type=offline because Google implementation deviates slightly from the specification and if you don’t the transaction will not generate a refresh token,
When using Auth0 as a broker, the response returned directly to the client application applies to Auth0 itself, more specifically, the issued tokens passed to the client application are Auth0 tokens. However, the user still authenticated through Google and there were still tokens issued by Google, including a refresh token due to how the request was performed; the difference is that those tokens are not directly surfaced to the client application. However, you can still obtain those intermediate tokens by going through the process described at: https://auth0.com/docs/tokens/idp
Have in mind that not all social provider authentication types brokered by Auth0 support retrieving a refresh token using the above process, but for the Google case it’s supported so you can achieve a similar end-result to the one you initially described.