I'm trying to authenticate a user on Android via Google Sign-in to get the account name, grab the token via GoogleAuthUtil.getToken(getApplicationContext(), app, scopes), and then send the token to my NodeJS back-end server to verify
I found this great stackoverflow question on how to decode it, cache the key id (KID) so it's not doing a round trip every time, etc. (haven't implemented this part yet, but sort of played around with it) My only question is: what's the difference between the following googleapis certs:
The KID on each version are identical, but the content is overtly different. Why? v2 and v3 seem to be almost identical except that v2 has an "==" appended at the end of the value of property 'n'
Most importantly, which version do I use?
I think these certs are called JSON Web Keys (JWK). I've also read the term 'x5c' What is that?
PS: The token I'm getting on my nodejs from my android app is:
{
"iss": "accounts.google.com",
"sub": "SOME_LONG_NUMBER_THAT_I_DONT_KNOW_IF_SHOULD_SHOW",
"azp": "SERVER_CLIENT_ID",
"email": "ANDROID_USER_EMAIL",
"email_verified": "true",
"aud": "ANDROID_CLIENT_ID",
"iat": "SOME_NUMBER",
"exp": "SOME_NUMBER",
"alg": "RS256",
"kid": "e53139984bd36d2c230552441608cc0b5179487a"
}
Version 1 appears to be a basic JSON mapping of key ids to certificate strings. I don't have any inside information, but I would speculate that this is a simple "home-grown" format that somebody at Google made up as an easy way to distribute their public keys.
As you have noted, versions 2 and 3 are distributed in the JSON Web Key (JWK) format. This format is defined in a formal specification, RFC 7517, which lays out exactly how to structure a JSON response representing cryptographic keys.
As for the difference between v2 and v3, it looks like v2 included trailing equal signs as padding and in v3 they've simply stripped those off.
I've also read the term 'x5c' What is that?
In the specification, 'x5c' is defined as an optional parameter for specifying a list of cryptographic certificates that together form a "chain of trust" that would allow a client application to validate the key by verifying each certificate in turn and following the chain back to a known, trusted root certificate.
Most importantly, which version do I use?
If possible, I would suggest using the most-current version. But as long as the keys themselves are identical, it probably doesn't matter very much.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments