I’m trying to get my head around how to use the ManagementClient API to call a third-party API (Google) after successfully authenticating.
I have read most other examples on the community and haven’t found the answer yet!
After successfully authenticating a user - I parse the id_token response from the authorization code grant flow, which gives me back the users information and the sub field (Auth0 ID) which I pass to another service.
On the other service I then use the management API to fetch the user via Auth0 ID to get the access token. I don’t receive a refresh token in the response regardless of requesting offline_access, correct scopes etc. (Problem 1 that I can’t solve)
If I cannot get the refresh token easily for offline calls to the Google calendar API, am I able to just call the getUser API endpoint from AUth0 and use the access token directly from that? My main concern is the expiration - I have called it locally and it returns an hour expiration - then call it again and it returns the a) same token, and b) same expiration - What is the best way to go here?
Thanks so much for the help, I’ve been stuck for a day or so so would love to get this solved in the correct way.
If your application is looking for a Google specific Access Token (or Google specific Refresh Token ) in order to call Google specific APIs - either directly, or via one of the many Google SDKs (such googleapis) - then you will typically need to redirect to the Google Authorization server directly in order to obtain said token. You can do this once authentication via Auth0 has completed, and it should be a seamless operation - i.e. the user should not be asked to interactively login - as the (Google) SSO session already established by authenticating via Auth0 will be used. You can find more on Google Authorization here.
For convenience, Auth0 typically stores the Access Token that might returned by an upstream IdP as part of first-factor authentication. And Auth0 typically stores such a token as part of the user’s profile record in the corresponding entry in the identities array, and accessible via a call to the Auth0 Management API. However, such tokens are typically short-lived, and typically are provided so that Auth0 Extensibility - such as an Action, Rule or Hook - can call upstream IdP services to obtain additional information about a user as part of the login process. Auth0 does not typically store any Refresh Token delivered by an upstream IdP.
A follow up question - the access token provided via the Auth0 Management API (identities array) doesn’t seem to change after it’s supposed expiration, nor does the token change.
Is this expected behaviour? Does Auth0 refresh that access token itself before returning the Management API response? (As I guess you never pass back an already expired access token)?
That’s correct Geordi. Auth0 won’t ever reach out to the upstream IdP to renew/refresh any access token delivered by it (the upstream IdP). The only time that this token will be effectively renewed/refreshed is if Auth0 requires the upstream IdP to perform first-factor authentication again - which typically happens when the Auth0 session expires.
