Hi
As I understand, the sign-in generates an {ID token, refresh token} pair. You want to do 2 things: verify the ID token, and refresh the ID token.
Let's take the first case: verifying the ID Token. The ID token is simply a signed JWT. The payload would look something like this:
{
"iss":"accounts.google.com",
"at_hash":"HK6E_P6Dh8Y93mRNtsDB1Q",
"email_verified":"true",
"sub":"10769150350006150715113082367",
"azp":"1234987819200.apps.googleusercontent.com",
"email":"jsmith@example.com",
"aud":"1234987819200.apps.googleusercontent.com",
"iat":1353601026,
"exp":1353604926
}
This JWT can be verified by any party that can use the JWKS published by google at this endpoint. Apigee has a built-in VerifyJWT policy, which can verify signed JWT via JWKS. The necessary policy configuration to verify a token issued by Google Identity is something like this:
<VerifyJWT name='JWT-VerifyGoogleIdToken'>
<Algorithm>RS256</Algorithm>
<!-- you may have to modify this to accommodate your needs -->
<Source>gauth_id_token</Source>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<PublicKey>
<JWKS uri='https://www.googleapis.com/oauth2/v3/certs'/>
</PublicKey>
<!--
Not sure about issuer in your case.
<Issuer>accounts.google.com</Issuer>
-->
</VerifyJWT>
Attach that policy into your Apigee proxy. After your proxy executes that policy, you can be assured that the ID Token is valid, was issued by Google, is not expired, and so on. The policy will extract all the claims from the payload (email, sub, possibly given name, etc) into context variables, which are accessible to subsequent policies in the API proxy flow.
If you want to validate that the iss claim is a particular value in the token (I am not sure if multi-tenant google identity uses a different issuer for each tenant or not), you can insert the Issuer element. If you want to validate the aud claim has a particular value, use the Audience element. Consult the documentation for the policy for more details on that.
OK That checks that the ID token is valid. If the token is expired, or not signed by google, or not present in the Source you specify, etc.... then VerifyJWT will fail, will throw a fault, and you can configure your API proxy to return an appropriate error message back to the caller in that case.
As for the second case, refreshing the token. It's my understanding that to refresh a token, your app must send a POST like this:
POST https://securetoken.googleapis.com/v1/token?key=[API_KEY]
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=[REFRESH_TOKEN]
And of course you can configure ServiceCallout to do that sort of thing.
But to make that happen, your API Proxy needs access to both the firebase API Key and the user's Refresh Token.
Effectively you are making the Apigee API proxy "the firebase client" in this case. At this point APIGEE would have a new ID token for the user, and you'd need to relay that back to the original client application I suppose.
LinkedIn
Twitter
