This is why OpenID Connect says to treat the user identifier as "issuer + subject" rather than email. This isn't even an OAuth problem as nothing in OAuth talks about using the user's email address as an identifier.
On Tue, Dec 23, 2025 at 6:14 AM Matthias Fulz <mfulz= [email protected]> wrote: > The problem is again you miss the main point: > > > it's not about issues with trust handling. It's all about MISSING TRUST > GRANTING of the Identity owner (USER) itself. > > Again think about the following: > > I've an account at service-cool-stuff with my mail [email protected] + pw > -> ok > service-cool-stuff enables login via Facebook -> oauth, etc. ok > I DO NOT HAVE ANY FACEBOOK RELATION!!!!!! > > Facebook says ok here is the login for [email protected] signed by us -> > service-cool-stuff trusts -> login valid POINT. > > Where is the part that I BY MYSELF have ever said that Facebook is allowed > to identify FOR ME ????? > > On 12/23/25 3:03 PM, Michael Sweet wrote: > > Matthias, > > I can't claim to be an OAuth expert, but as someone who has been implementing > OAuth/OIDC support for CUPS/IPP over the last couple years I can say that the > Resource Server still has to validate the access tokens it is being provided > with, either using introspection or via verification of RFC 9068 JWT bearer > token signatures. That requires a trust relationship between the RS and AS, > which usually involves a human configuring things and X.509 certificates and > potentially other credentials being validated along the way - you don't just > accept any old token without validation, and you don't accept any AS without > configuration/approval. And if an access token is revoked (not just expired) > then the refresh token should also be revoked in order to force > re-authorization, right? > > Assuming there *was* an AS implementation that allowed malicious users to > provide arbitrary emails without verifying that said user had access to that > email account, you'd need someone with access to configure the RS to *use* it > ("Sign in with Gooogle" -> accounts.gooogle.com -> users authorize through > phony Google AS and don't notice the extra "o") before this issue would even > be possibly exploited. > > Similarly, if there is an OAuth-based service that doesn't follow best > security practices and allows revoked access tokens to be renewed, that would > be a problem with the implementation and not the protocol. > > > > On Dec 23, 2025, at 8:22 AM, Matthias Fulz <[email protected]> > <[email protected]> wrote: > > Ok guys, > > I've tried to target ietf detailling the issue at a technical > level:https://www.ietf.org/archive/id/draft-fulz-oauth-trust-binding-00.txt > > PLEASE, PLEASE check this out it should really clarify the root issue, that > still misses. > > In concrete terms, the current OAuth trust model is equivalent to allowing > third parties to mint new access keys for your house without your prior > consent, as long as the lock manufacturer has pre-approved them. Even if you > later revoke one such key, the same party can immediately issue a new one, > without any additional authorization from you as the owner. > Revocation is therefore not a security control, but merely damage control > after access has already been granted. > > This highlights the core flaw: OAuth allows unilateral identity assertion by > authorization servers, while the actual identity owner has no cryptographic > or protocol-level mechanism to pre-approve or deny that specific trust > binding. Trust is implicitly inherited through shared identifiers (e.g., > email), not explicitly granted. In any other security domain, a system where > an attacker can endlessly re-issue valid credentials after revocation would > be considered fundamentally broken. > > To sum it up: > In its current form, OAuth permits infinite credential re-issuance by > pre-trusted identity providers without explicit consent from the identity > owner, rendering revocation a reactive measure rather than a security > boundary. > > > BR, > Matthias > > On 8/9/23 10:05 PM, mfulz wrote: > > Anyone read this topic or could tell if there is a better place to adress > this? > > Sent from Nine > Von: mfulz > Gesendet: Sonntag, 16. Juli 2023 03:38 > An: [email protected] > Betreff: [OAUTH-WG] OAuth Trust model > > > > Hi Together, > I was thinking about some (at least I see it in that way) problem in the > whole oauth/openid design: > The problem is the following: > The user has no control about what providers are accepted by the clients > (websites, etc.) and this opens access to these providers without any way to > protect against that. > Example: > I've created an account with email/password login at stackoverflow > I've created an account with the same email at github > -> logged out from stackoverflow > -> logged in via github oauth -> working and connected to the email/pw > account from stackoverflow > > Stackoverflow has the possibility to remove the github login now, but the > main problem is, that I would be out of control, that some of these oauth > providers > (please don't go into the discussion WHY they or anyone should do it) could > access my accounts, when such site would allow them as provider. > > In my opionion it would be good to avoid such issues, by including something > in the standard, that the user MUST allow the connection on both sides on the > client > and on the provider. > > Yes for sso without any existing account that's some kind of an issue, but > still it could be added some verification process like sending confirmation > link > That the user is accepting the oauth provider on the Client side. > Then the oauth provider would also need access to my emails to access my > account. > > Not sure if I'm wrong here but I think my description is correct. > > BR, > Matthias > > _______________________________________________ > OAuth mailing [email protected]https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > ________________________ > Michael Sweet > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
