"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
