3

We are currently using Google OpenId Connect to authenticate our users.

I'm successfully retrieving the access token and id token via the token_endpoint as described here. Later on I validate the id token as described here. The token_endpoint will be received via the discovery document (as recommended by Google).

Problem

But since a few days there seems to be a new version of the discovery document, because the token_endpoint has changed from

https://www.googleapis.com/oauth2/v3/token

to 

https://www.googleapis.com/oauth2/v4/token

The new endpoint returns a slightly longer id token which can no longer be validated with https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=xxx. The request returns with the error

{
 "error": "invalid_token",
 "error_description": "Invalid Value"
}

If I hard code the token_endpoint to the old url (https://www.googleapis.com/oauth2/v3/token) everything works fine like before.

Question

Since the old OpenID 2.0 has been shut down a few days ago, I thought there may be some correlation between the shutdown, the new token_endpoint and the validation of the id_token, but I couldn't find anything yet.

Is there any solution to validate the new slightly longer id token via the https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=xxx url? For debugging it is easier to use the tokeninfo endpoint, later on in production we'll probably validate the token locally (Validating Google ID tokens in C#).

Community
  • 1
  • 1
Robar
  • 1,929
  • 2
  • 30
  • 61
  • 1
    You're right, there was a [new version](http://stackoverflow.com/q/29830503/72176) of the discovery document published last week. It looks like there is a bug in `tokeninfo` (which is not actually part of OpenID Connect, but I agree is a useful tool during development). As a temporary workaround, you could go back to the old discovery document (and thus get the previous format id tokens), or avoid using `tokeninfo` and implement your local ID Token validation now. This is a handy online tool for [inspecting JWTs](https://py-jwt-decoder.appspot.com/) during development. – William Denniss Apr 28 '15 at 17:06

1 Answers1

1

The invalid_token error was caused by an issue in v1/tokeninfo, related to the modified ID tokens from the v4/token endpoint, as you suspected. That issue has been resolved, and tokens should validate correctly again at tokeninfo. Thanks for your detailed post!

Community
  • 1
  • 1
William Denniss
  • 16,089
  • 7
  • 81
  • 124
  • Thanks for your answer, yes it seems to work again. But because I had some time on my hands yesterday I implemented the local validation (as you suggested). The implementation is based on this answer: http://stackoverflow.com/a/29779351/333404. For debugging it is nice that `tokeninfo`works again. – Robar Apr 29 '15 at 06:23
  • Awesome! Local validation is definitely preferred when you go to production, so your time was well spent :) – William Denniss Apr 29 '15 at 20:49