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 <http://www.9folders.com/>
------------------------------------------------------------------------
*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]
