"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
