Yes and THAT IS THE PROBLEM: OAuth SHOULD take CARE about! It's the core
protocol and it totally ignores the Identity Owner itself in the whole
trust model.
Seriously that could be easily circumvented inside the protocol and
would remove all that issues, but first the people must understand what
that means.
think about something like german dsgvo: It's illegal to provide third
parties access to personal data (especially identity itself) without
consent.
Now I could start to issue law enforcements to every site I'm using
which is providing login via as that's exactly what it means at the end.
Why please WHY can't the core protocol itself not be the responsible
part to integrate such simple trust model to avoid everything that's not
helping anywhere????
On 12/23/25 3:23 PM, Aaron Parecki wrote:
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
<[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 <http://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]
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]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
________________________
Michael Sweet
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [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 [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
