41–50 of 297 posts
> “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”. 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…
I agree, in my limited experience the sub remains consistent even when changing the Google Workspace domain. So the email changes but sub remains the same. The issue seems to be clients matching on email/hd claim instead. 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.
It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…
Yes, it's a failure on DankStartup's part. Not really much different than a user buying dankstartup.net, setting up a catch-all email, observing what comes in, and performing password resets for those accounts, allowing for account takeovers. Calling it a vuln in oauth may be a bit hyperbolic, but Google could help prevent it.
Still, I wouldn’t call this a vulnerability on the service provider’s part, it’s just user negligence.
I really don't understand here, the proper way to use Google's OpenID implementation to authenticate someone is to use the `sub` claim. Don't use the email, don't verify it yourself, use the `sub` claim. It's a known fact and is properly documented[1]. If the `sub` changes, it's because it's not necessarily the same person so have a flow ready for that. It could be an employee left and came back, a domain change, an…
> “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.
It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…
> Suppose DankStartup folds … Isn't that a failure on DankStartup's part, to not shut down their business accounts? Expecting an entity that has already failed* to not fail again isn’t an effective security control, unfortunately. * - not every startup that folds has “failed”, but the point still stands
Sure, I'm sympathetic to that, but again I don't see how that's within the scope of oauth.
I really don't understand here, the proper way to use Google's OpenID implementation to authenticate someone is to use the `sub` claim. Don't use the email, don't verify it yourself, use the `sub` claim. It's a known fact and is properly documented[1]. If the `sub` changes, it's because it's not necessarily the same person so have a flow ready for that. It could be an employee left and came back, a domain change, an…
Thankfully, apparently this only affects Americans.
It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…
The contention isn't that you can impersonate DankStartup, that's obviously not a vulnerability since you are indeed the domain owner. It's that former entities with DankStartup accounts might have used OAuth to create relationships of their own. And when the startup folds, they don't magically disappear. Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the own…
Earlier quoted context omitted.
The contention isn't that you can impersonate DankStartup, that's obviously not a vulnerability since you are indeed the domain owner. It's that former entities with DankStartup accounts might have used OAuth to create relationships of their own. And when the startup folds, they don't magically disappear. Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the own…
> Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the owner of the domain to impersonate Sally in the context of that relationship. I don't think this is the issue, unless someone went to some pretty extreme lengths. Configuring OAuth such that the company Google Workspaces account is recognized by Taskrabbit as a valid SSO option is not as simple as signing u…