I read all the comments carefully while flying through Brazil, and I
confess that my reasoning from the beginning tended to say that the
OAuth trust model is “as is” and that the main point of the trust
relationship is between the AS and the RO (in this case, a user).
At various times, while reading, I agreed that Matthias' question was
about a problem that would not fit directly into the OAuth Framework,
as I understood that the central point in question was authentication
and not authorization. But I refused to accept that my point of view
would be correct due to the avalanche of exposed reasoning that
contributed to my understanding and that even so, Matthias insisted on
making himself understood by different approaches, leading to believe
that he understood the answers, but still did not was convinced that
we had understood this problem in essence.
So, during the flight, I reflected on Matthias' insistence: "What
could we be missing?" Brilliantly, I think Matthias raised a very
important and fixable point: “That the user MUST allow the connection
on both sides on the client and on the provider.”
As is known here, OAuth 2.0 is not a ready-to-use protocol, but a
framework that is constantly evolving, it is specified by multiple
RFCs and its main implementation is the OpenID Connect 1.0 layer,
which is also under development. I say this because I believe the
solution to this point raised by Matthias would result in a Zero-Trust
Authorization Grant with great value to the protocol, as it would
reinforce user authorization so that the AS could authorize client
applications.
In this grant type, the AS would ask the user to sign evidence tokens
to authorize client application access in the authentication/consent
phase. Of course, this flow would require some restrictions to
maintain a high degree of security, such as: Generation and storage of
user signature keys; Form of registration of the signature
verification key with the AS; Transport of authorization evidence to
the client application; Transporting the evidence token signature
verification key to the client application; etc;
I believe that a Zero-Trust Grant Type with a model similar to the one
above would be very useful for Web 3, financial applications (FAPI /
Open Banking), etc. It would also encourage the use of private keys to
authenticate users in these environments, making room for the signing
of operational tokens in the future (out of scope).
Therefore, I ask Matthias to validate and complement, if possible, my
point of view. And I invite this group to start an effort to draft
this Grant Type with me.
Em qui., 10 de ago. de 2023 às 22:21, Michael Jones
<michael_b_jo...@hotmail.com> escreveu:
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 <oauth-boun...@ietf.org> *On Behalf Of * Dick Hardt
*Sent:* Thursday, August 10, 2023 5:46 PM
*To:* Matthias Fulz <mf...@olznet.de>
*Cc:* oauth@ietf.org
*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 <mf...@olznet.de> 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
<mf...@olznet.de> 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
<mf...@olznet.de> 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 <mf...@olznet.de> 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 <mf...@olznet.de> 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
<mf...@olznet.de> 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:* oauth@ietf.org
*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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
