How to get the id_token JWT from Google authenticator?

we’ve been looking everywhere how to get the id_token JWT when using Google Authenticator in jupyterhub (on kubernetes).
We get the access_token and other user info, but not that one.

It seems the authenticator code is not requesting for it, and so it doesn’t end up in the auth_state.

Anybody doing SSO auth with google and setting an env variable to the JWT that could give us a hint by any chance?

Thanks for any clue you may have

adding some context.

We tried to extend the GoogleOAuthenticator, and got it to call our authenticate method. Though the id_token is empty.

      from import GoogleOAuthenticator
      class UbyreGoogleOAuthenticator(GoogleOAuthenticator):
        async def authenticate(self, handler, data=None):
          user = await super().authenticate(handler, data)
          user['id_token'] = handler.get_argument('id_token', '')
          return user

It’s because the underlying code making the call to Google doesn’t request for the id_token.
That’s done in the code of the HubOAuth that creates the request with just the response_type set to code. What we would need is the response_type to be code id_token

See in the _login_url method
def _login_url(self):

Did we miss something somewhere that would allow to change this behavior without having to change the core code of JupyterHub?

HubOAuth is used for internal OAuth between JupyterHub components/services. User authentication is separate, and is completely handled by the Authenticator.
The source for the GoogleOAuthenticator is

Yes you can for sure say that I am confused between the HubOAuth role and the Authenticator role in all this. :slight_smile: Thanks for pointing this out. :stuck_out_tongue:

I’ve looked at this Google related code multiple times actually.
We couldn’t find a way to get the id_token by extending it.
The google authenticator code doesn’t have anything related to id_token either.
Our understanding is that the id_token is returned by Google when the openid scope is included, which it is by default in the code, and we add it also in our helm chart config for good measure.

We have a work around using just the access_token/refresh_token now, so it’s not blocking.
Would have been super nice if we had been able to get that id_token JWT instead for the integration with our own auth backend.