Support verification of the `hd` parameter for Google

[dingo15]

Considering the latest issue with Google described at https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of/, I believe it's reasonable to validate the hd parameter returned by Google.

According to https://developers.google.com/identity/openid-connect/openid-connect,

hd is

The domain associated with the Google Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization.

The Google recommendations are here: https://developers.google.com/identity/openid-connect/openid-connect#validatinganidtoken

Be sure to validate that the returned ID token has an hd claim value that matches what you expect (e.g. mycolledge.edu). Unlike the request parameter, the ID token hd claim is contained within a security token from Google, so the value can be trusted.

At this point, as far as I can see, there are no hd parameter checks in place.

[dingo15]

Hi team! Are there any updates here?

[JoelSpeed]

Has anyone tried to reproduce this? When you send the hd param as a request entity, Google pre-fills (and forces) the domain to be the correct HD. I would have expected that Google wouldn't let you login if the request hd doesn't match the account hd. I don't have access to a Google org anymore so can't test this, but that certainly used to be the case

[yaegor]

@JoelSpeed I confirm that the issue is easily reproducible (one can pass OAuth2 Proxy checks for domain with Google's "unmanaged" account - one created using "Use your existing email" during Google account creation). AFAIK "hd" parameter passed on redirect to Google Sign-in is just a helper which pre-fills the domain for the user, but user can still override it by entering any other domain. However, this is not relevant here as the issue is that user signs in with the Google account in the required domain, it's just that it is an "unmanaged" account. Important is to verify the "hd" claim in the resulting Google ID Token - it is only present if the user belongs to exisitng Google Workspace/Cloud organization with the specified domain. The originally linked Google documentation now states about "hd" claim:

"The absence of this claim indicates that the account does not belong to a Google hosted domain."

and for the "email" claim:

You also can't rely on the domain of the email claim to identify users of Google Workspace or Cloud organizations; use the hd claim instead.

[yaegor]

@JoelSpeed Just a reminder that this is an open security issue which needs triaging.

[tuunit]

@kvanzuijlen potentially something relevant for you to work on?

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[yaegor]

This is a still standing security issue. The impact has reduced a bit as Google has recently prohibited creation of new unmanaged accounts in the organization domains, but those who have created such accounts before can still log in via oauth2 proxy which can grant unauthorized access in certain cases. I still have access to such a Google account and can verify the fix when (if!?) implemented.

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[yaegor]

Still relevant as per my previous comment. It is concerning that a security issue gets handling like this.

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[yaegor]

As per the comments above, the issue is still relevant. Let me remind that this is a security issue which results in unauthorized access in certain cases. It would be appropriate to file a CVE and fix the issue.