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]>
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]
