Guardian and Google OAuth2 keys rotation

Phoenix Forum Questions / Help
,
1

Hi,

I am using ueberauth/Guardian to authenticate users against google. It works, but I have a problem with keys rotations that google executes: ueberuath makes the challenge phase, and guardian receives the token and verifies it, extrapolating claims etc etc

My problem is that Google rotates the keys (which are here: https://www.googleapis.com/oauth2/v3/certs) and I don’t understand how to deal with such rotation. There’s no info on which one of the two to use. Also, reading here:

it states:

These keys are regularly rotated; examine the Cache-Control header in the response to determine when you should retrieve them again.

but does not tell anything more.

How should I handle this key rotation ? Which key should I use in what case ?

Thanks !

2

OAuth2 gives access tokens to access user data, they have an expiration (Cache-Control) at which point the oauth2 server should be contacted again to update it or so (or if the user logged out of the oauth2 server then you’ll log them out of your system now too). Guardian I don’t think has anything to do with this whatsoever? Ueberauth just does the initial auth, it is up to ‘you’ to do it again later if needed.

3

You have to try validating signature against every suitable key. A suitable key is a key whose:

  • "use" member is not set or is set to "sig", and
  • "key_ops" member is not set or contains "verify", and
  • "alg" is not set or set to the OIDC client’s registered "id_token_signed_response_alg" if set (or the default "RS256" otherwise)

I’ve developed libs (JWKSURIUpdater and JWKUtils) for personal projects that you could be interested in.

1 Like
4

I think I got the point. In the first part of the token [*], we have a bunch of information:

%{
  "alg" => "RS256",
  "kid" => "762fa637af953590db8bb8a636bf11d4360abc98",
  "typ" => "JWT"
}

The kid info is the one that gives us the chance to recognise which key has been used to generate the token you have received, and so which one to use to verify it.

So, what I have done, I have created a custom secret fetcher that applies this logic, and everything works. I am using it like this:

MyApp.GoogleGuardian.decode_and_verify(token, %{}, secret: SecretsFetcher.get(token))

The only feeling I have, is that maybe there is a way to implement this in a more Guardian-designed way; but I am struggling to find some real examples of this.

[*] the token is made of 3 parts, separated by a .; the first one is the one that contains the info (and it’s B64 encoded).

1 Like
5

OAuth2 is made by two phases, with the first one being the “challenge” one, which is basically when you authorize the application after being redirected to the SSO implementation you are using (Google, in my case).

After this, ueberauth kingdom ends, and you have to handle the token. Guardian kicks in, but my question was about the multiple keys were to be used; this was the smoky part to me, sorry if I have not been very clear.

6

Indeed if a "kid" is present, you shall use it! With JOSE you can use JOSE.JWS.peek_protected/1 to retrieve the header.

1 Like