What I don't understand is why the `sub` claim is not consistent for those users at Google. To my understanding of the OIDC protocol the `sub` should be unique for a specific user.
Additionally as far as I understand if you take over a defunct domain and create a new google workspace with new users those new user account should get assigned a new `sub`.
I wonder what action is causing the sub to change like the author suggests is happening.
That's most likely dependant on how the IT department handled the deprovisioning/provisioning of users in our Google Workspace, I unfortunately don't have the details for that.
Indeed this would be very interesting.
This issue is also very similar to CVE-2024-25618.
What we did to mitigate this is the following: - Federated login with OIDC - Look for a user based on the sub claim - If they are found: authenticate that user and optionally update their profile (email, name, ...) based on then new id claims. - Else look for a user matching on the `email` claim and link the `sub` to that user - If no user is found create a new one
I don't think the article clearly states one way or another whether those 0.04% of sub claims changing are legitimate end user changes or not. If those sub changes are legitimately the Google Account changing, I don't think that's a bug on Google's part, but rather is a problem on the clients' side for not validating the sub claim.
If the sub is changing without the Google Account user actually changing, maybe something internally at Google is swapping out those IDs when it shouldn't be. It doesn't look like a UUID from the example I saw, so maybe there's some code somewhere to just change the user's ID if there's a collision or something?
Interestingly, I don't think Google claims that Sign in with Google is fully OIDC-compliant. At least in the overview I linked in my comment, they compare the implementation to OAuth+OIDC, but I'm not sure they claim to be 100% spec compliant.