I HIGHLY recommend the authoritative blog post on the subject “OAuth 2.0 and
Sign-In”, written by a dear friend to many of us, Vittorio Bertocci, just over
a decade ago. While Microsoft took it down, it lives on in the Wayback Machine
at
http://web.archive.org/web/20130105031040/http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx<http://web.archive.org/web/20130105031040/http:/blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx>.
It authoritatively covers much of the ground in our current discussion.
Read and enjoy!
-- Mike
From: OAuth <[email protected]> On Behalf Of Dick Hardt
Sent: Thursday, August 10, 2023 5:46 PM
To: Matthias Fulz <[email protected]>
Cc: [email protected]
Subject: Re: [OAUTH-WG] OAuth Trust model
Sorry -- I have not read this thread in depth, so if you have another crisp
example, please send.
Your description sounds like an identity problem and not an authorization
problem. OAuth solves the latter, and it is a feature that the RS does need to
know the client, only that the client is authorized.
To fit that into your analogy, anyone the school deems authorized to pick up
the kid is authorized to pick up the kid. If you don't like how the school
decides that, don't send your kid to that school, or work to change the
school's policy.
On Thu, Aug 10, 2023 at 4:41 PM Matthias Fulz
<[email protected]<mailto:[email protected]>> wrote:
I'm running out of ideas to get the point explained...
Ok let's try it from an abstract view:
Think about a school where your kid is allowed to get picked up by a
legitimated list of persons -> ok
Now think about the school saying I'm trusting a third party about identifying
any person on that list, without asking the person about that this third party
is allowed to identify this person.
The problem is, that by design the person who's identity is to be verified has
no control about what AS is allowed by the site to verify the identity.
Sorry for that stupid example but I'm really not able to explain the issue in
another way anymore :(
On 8/11/23 00:02, Dick Hardt wrote:
This sentence does not make sense to me "which AS is AUTHORIZED at which RS
acting as the user"
The RS server has delegated authorization decisions to the AS
The client is acting as the user
On Thu, Aug 10, 2023 at 2:59 PM Matthias Fulz
<[email protected]<mailto:[email protected]>> wrote:
I can follow your point but please try to think from a different perspective:
As authorization protocol, how can it not let the user decide which AS is
AUTHORIZED at which RS acting as the user?
On 8/10/23 23:28, Dick Hardt wrote:
"auth providers" is an extremely confusing term.
OAuth has no involvement in the content an RS provides the client -- the AS
only provides authorization to access the content at the RS.
It is common that the AS and RS are the same entity, but the protocol is
designed to have a separation of concerns so that they are acting independently.
From what I can understand in your discussion, you are wanting OAuth to do
something it is not designed for.
On Thu, Aug 10, 2023 at 2:03 PM Matthias Fulz
<[email protected]<mailto:[email protected]>> wrote:
On 8/10/23 10:25, Warren Parad wrote:
You've lost me at this:
Some site, which I'm registered in is trusting some oauth provider I'm not even
knowing about. I'm not registered at this provider. If this provider is
(independent how or from whom) is used in a malicious way, they can access my
account, without my knowledge by sending a valid token including my email.
Nothing stops a site you are using, registered with your email address, from
just selling your data to a third party, or blanket publishing it publicly.
There is nothing we can do to stop this unless the data we care about is
encrypted on the client side. OAuth doesn't really have anything to do with it.
Yes but that's the point: The site itself has to do it. If they are not willing
to it's ok.
But: With the actual concept using auth providers, even if the the site is NOT
willing to sell it, my account could be accessed by using the trusted auth
provider without the site itself needs to do anything. And the problem is, that
such sites wouldn't be technically forced to use such auth providers by active
permission granting from user side.
That's the difference I'm trying to point at.
Sorry I'm really struggling to explain it in another way (will think about).
Because it has nothing to do with OAuth, the suggested solution of course must
have a hole with it. And indeed it does. What if the site offers the token
strategy, but then decides to outsource the whole authentication process to a
different third party? We are back at the same problem again. However it sounds
like what you are saying is that there should be a standardized mechanism for
handling the site <=> user token verification. If we use OAuth terminology that
would be: We should allow step-up authentication to occur solely between the
resource server (RS) and the user agent without involving the authorization
server (AS). But then who generates the new JWTs? If the AS generates the new
one then, we didn't stop anything. And if the RS generates the new one then
actually the AS isn't needed to do anything.
No that's not what I was suggesting.
It's not about excluding the authorization server it's more about a additional
verification, that the user is granting the RS explicit permission to use the
AS on behalf.
AFAIK the actual situation is the following:
The site is providing the login via AS and the AS can then on behalf any user
of this site just login. The site can of course implement some permission
granting but that's not required. This is done via signed JWT, etc. which are
verified on the RS side.
Now my suggestion would be more like adding an additional verification before
the AS can be used:
The following is just some rough idea on how to add such verification in a safe
way
The RS side will use a signed jwt that will be included into the access token
send from AS to verify that the user has granted permission to use this AS.
This could be done automatically during registration, so it wouldn't break this
feature in a way that the RS will create this token during registration and
send it to the AS. The AS will need to include this token for requests and if
this cannot be verified on the RS side it will not be accepted.
Further (ae. existing accounts) the user could provide a signed jwt to the AS
and a pub key to the RS. If the jwt cannot be verified than the user did not
granted the permission to use the AS on behalf.
For companies, etc. using RS / AS on premise this could all be implemented to
be done automatically and it would not create any additional effort on
administration side.
And that latter case is actually the reality if we consider these tokens to be
a 2FA mechanism that is managed by the site/resource server. So I read this as,
we should standardize WebAuthn communication between a user agent and the
resource server. That already exists though, doesn't it?
Yes and no: Think about the widely used TOTP (ae. github) the Secret Key is
created on the AS side and therefore under full control of it. This is not
helping to protect the user from malicious intents.
On Thu, Aug 10, 2023 at 12:59 AM Matthias Fulz
<[email protected]<mailto:[email protected]>> wrote:
I'm trying to explain my concern more deeply, please try to follow my thinking.
First: Everything you've written is correct and I fully agree.
But: The difference is: I'm deciding, that I'm using email from xy, I'm
deciding, that I'm using this email to register at some site or anything.
Anything of these services could be hacked of course, and then they can use my
mail to reset password, use the accounts, etc.
Now think from the other side:
Some site, which I'm registered in is trusting some oauth provider I'm not even
knowing about. I'm not registered at this provider. If this provider is
(independent how or from whom) is used in a malicious way, they can access my
account, without my knowledge by sending a valid token including my email.
I'm not sure how to explain the main concern about this in more detail and of
course I can avoid services providing these type of logins without my
permission, but as said what about the future?
On 8/10/23 00:40, Warren Parad wrote:
Let me try that differently, is OAuth more vulnerable than email usage? If you
hacked any email provider that's arguably a bigger goldmine than just ones
protected by oauth. As long as sites are protected by email, oauth gives a more
secure strategy. Most providers that accept email as authentication allow you
to reset your password via email.
Going further, "email is insecure" because providers that send email can
impersonate you. How about telecom companies, they can pretend to send SMS from
you. Or the government, they could issue a new password in your name and
pretend to be you. The horror.
In all seriousness, it's about your threat modal more than anything. Concerned
about your email, then that's your weak point, concern about oauth, we'll first
be concerned about your email, and then you can be concerned about oauth.
If we assume that everything was on oauth, then there's the question of why
don't providers just implement a FIDO2 compliant strategy. Wouldn't that solve
everything?
Don't get me wrong: I'm not telling everything is on oauth as far (I'm not so
deep into the protocol) it's acting only as authorization not as
authentication, than it is anyway the wrong point to address this issue.
But if it would be possible to eliminate this specific issue inside the
protocol directly, it would be the best solution to not even run into this
situation at any later point of time.
As total naive approach I could about something like:
Client is trusting Provider for user authentication/authorization
Client must set some random verification token (normally requested / set by the
user)
User is registering this token under the provider
Only if this token is valid the token is accepted by the client
If something like this would be included in the protocol itself, it would be
working in all situations like companies because they can control both sides
and generate such tokens automatically
And yes if the site is working together with the provider than it's over, but
that's exactly the point: Than the target itself must be included not only the
single provider, where the user might not even have an relationship with.
Further I could think of extended security, by using signed tokens with user
provided public key, so it's technically secured to just fake tokens.
On Thu, Aug 10, 2023 at 12:27 AM Matthias Fulz
<[email protected]<mailto:[email protected]>> wrote:
Thank you for the responses so far.
On 8/9/23 22:20, Warren Parad wrote:
I can tell you I definitely read it. I actually read it multiple times. But I
don't know what to tell you. The problem you've identified exists, but that
doesn't necessarily mean it is a problem. In a way it is a bit like, You create
a bank account at a bank and you give them all your money. They then decide to
never give it back.
Yep I know, but the difference is, that I've full control over my decision to
give my money to this bank or not.
While banks are regulated in most countries and things like GitHub are not, in
essence this interaction is based on trust. Of course solutions like WebAuthn
via FIDO2 used as a first party authentication can solve this, and arguably
this is the remit of the entire web3.0 domain.
I don't think anyone would suggest this isn't a problem, just that it isn't
that big of a problem. I think realistically, in order for this problem to have
a closed form solution, it would need to start with a suggestion on how to
solve it, rather than a bunch of us agreeing that it is. Because right now
there doesn't seem to be any fundamental solution available for this. And
honestly, the bigger problem is the digital assets at risk at the third parties
is not due to impersonation, but just general negligence. GitHub isn't trying
to malicious log into my StackOverflow account, and Google isn't trying to log
into my bank. That's because these organizations have supposedly bound
themselves to not grant this ability to their internal engineers to abuse. And
they are spending tons of resources attempting to stop external attackers.
That being said, it's hard to know if this problem hasn't already transgressed
in the wild. While it is certainly possible, it seems internal users are more
likely to act maliciously on behalf of the user via their owned data in their
own company, rather than attempt to impersonate their users at third party
sites.
These points are totally correct, but I think also about something like
official Authorities (ae. Patriot Act, etc.) that would definitely be
interested in such things (ok not on me personally), but this is another topic.
For me to be more safe, I'm using now a unique mail for Github, etc., which is
sufficient for now, but if you think into the future and especially about oauth
with more than a handful widely used trusted Providers and that they could be
hacked, infiltrated forced to grant malicious access, etc. Than this could
become to a huge problem in no time.
As example: Think about one widely used trusted provider that's hacked, or
similar. You could access so many accounts on multiple sites, even if the users
are never used this oauth for these sites.
Sorry to insist here, but just because it is not an issue now, I can't agree
that this not a big deal in general.
I mean in the above scenario even a unique mail wouldn't help because that
could send any mail, they want to these sites. Think about such provider acting
malicious and you would not even HAVE an account at any of them: every site,
that trusts them could be accessed under your account just by knowing the user
identifier, which is in 99% time the mail.
- Matthias
- Warren
On Wed, Aug 9, 2023 at 10:06 PM mfulz <[email protected]<mailto:[email protected]>>
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]<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]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
