Even in this case, you should not be automatically connecting accounts without proof of account ownership.
If I go to your service with an account that says I'm [email protected] <mailto:[email protected]>, I should not be able to take over the account of [email protected] <mailto:[email protected]> without them approving the connection it via email / password. If you're automatically connecting accounts based just on the email and doing no other confirmation, you're doing OAuth security wrong. That's my 2c on it anyway. — Emelia Smith > On 23 Dec 2025, at 15:14, Matthias Fulz <[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] > <mailto:[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] > <mailto:[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]> >>> <mailto:[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] <mailto:[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 list >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> ________________________ >> Michael Sweet >> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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]
