I have an application that relies on access to Google Calendar. And, until now, I have authed through a “Sign in with Google” option, requesting the needed Calendar scopes.
What I’m trying to accomplish: I would like allow Okta customers the ability to authenticate (mostly so I can support the SCIM management). The trouble is I am not clear on how to retrieve the needed Google auth credentials to access the Google Calendar API.
Where I’m at, so far:
In my own Okta instance, I have successfully configured Google as an IDP, and can authenticate (OIDC) into Okta with my Google credentials, from my Node app. However, the
refresh_token are all relevant to Okta, not Google.
Is there a way to get the needed Google authorization elements, from my handshake with Okta?
You probably want to take a look at this request to get the user’s tokens for their IdP instead of Okta: Identity Providers | Okta Developer
@andrea Thank you for your help. I am able to get both the
access_token and an
id_token, though I’m not quite clear what I can do with that last token.
The Access Token works great… until it expires. And re-authing into Okta does not retrieve a new token. One needs to go to the Okta portal and sign out, in order to get a fresh token.
So this leaves me with two other bits of info I’m looking to track down:
- The IDP’s (Google’s) Refresh Token. Normally, you need to go through Google’s “offline” OAuth2 handshake to retrieve this. But Okta is handling the auth here. Is there a way, that you’re aware of?
- The IDP’s UserId/ExternalId. The ID that I’m getting through OIDC does not appear to work (I assume it’s the Okta ID).
@andrea Thank you for your response and your help stepping through all of this.
- I fully appreciate Okta’s role in the authentication effort, here, and understand why you don’t currently request a refresh token. But if I can’t retrieve a refresh token from the IDP (Google, in this case), then integrating with Okta becomes more of a headache than an opportunity; requiring a second auth consent. Do you have any suggestions on retrieving this, outside of a second, direct-to-Provider OAuth handshake?
- Thank you. You were right on the money! I was having trouble with the “validation” step, but the decrypted
token_id does have the
sub property, which is that external User ID.
Bumping this to see if anyone has any better thoughts on this.