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 to [email protected]
________________________
Michael Sweet
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
