On Thu, Aug 10, 2023 at 9:40 PM George Fletcher
<george.fletcher=40capitalone....@dmarc.ietf.org> wrote:
Hi Matthias,
First, OAuth is about authorization and NOT authentication. If you
are concerned with Authentication then this thread should move to
the OpenID Connect working group mailing list :)
Allow me to set the public record straight on this before it starts
to lead its own life: OpenID Connect does not deal with Authentication
- at all - and in fact has the very same relationship with
Authentication as OAuth 2.0 does: at some point user Authentication
may happen, but it is completely undefined and orthogonal to the
OAuth/OIDC protocol. OpenID Connect should rather be thought of as
delegation of access to a user's identity (thanks to Justin who - I
believe - posed the latter definition). I guess you actually meant to
say "Identity" in the 2nd sentence above instead of "Authentication",
and I agree that this discussion seems to be about OIDC indeed.
Second, if I'm understanding the problem correctly, the issue is
NOT with OAuth (the protocol) or the Authorization Server. The
issue is with the "relying party" where the user originally signed
up with an email address (e.g. f...@example.com). In the case
described, the "relying party" took the email address provided by
the authorization server and looked in its own identity store to
see if there was a match. It found a match and automatically
linked those "identities" (in an attempt to help ensure the user
does not unintentionally create multiple identities when they
didn't intend to). The RP could present a page to the user to ask
if they want to link the identities and then if the user does want
to link, verify the user is the correct owner of the original
account before linking.
I agree that account linking really only happens when the user has an
authenticated session at the RP, possibly asking to re-authenticate
once more. In that case the user explicitly trusts the Provider, and
whatever the Provider can do afterwards is a result of that - as goes
for any trusted IDP - which addresses Matthias's 1st concern. This
also means that the 2nd concern - "unsolicited linking" - is not
possible IRL and certainly not in the Stackoverflow/Github example. It
is true though that "explicit (re)authenticated account linking" is
not included in any RFC/BCP, then again account linking in itself
isn't since it is not (very) protocol-related.
So for me, resolving this issue is out of scope for the OAuth
protocol.
Agree, OOOOAuth for sure ;-)
Hans.
On Thu, Aug 10, 2023 at 4:25 AM Warren Parad
<wparad=40rhosys...@dmarc.ietf.org> 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.
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.
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?
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
<https://urldefense.com/v3/__http://www.9folders.com/__;!!FrPt2g6CO4Wadw!MlSwGmLXZv9Fk8bOm3ICOR_rDeHxyrRd0u6TNWJeCKePl7SeuwJOm6LBE9fN4f7RxPkn036feigrU9JJeQDQOW6sAkk9jzet0lBo9Ww$>
------------------------------------------------------------------------
*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
<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MlSwGmLXZv9Fk8bOm3ICOR_rDeHxyrRd0u6TNWJeCKePl7SeuwJOm6LBE9fN4f7RxPkn036feigrU9JJeQDQOW6sAkk9jzeti_9Nmxo$>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MlSwGmLXZv9Fk8bOm3ICOR_rDeHxyrRd0u6TNWJeCKePl7SeuwJOm6LBE9fN4f7RxPkn036feigrU9JJeQDQOW6sAkk9jzeti_9Nmxo$>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MlSwGmLXZv9Fk8bOm3ICOR_rDeHxyrRd0u6TNWJeCKePl7SeuwJOm6LBE9fN4f7RxPkn036feigrU9JJeQDQOW6sAkk9jzeti_9Nmxo$>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MlSwGmLXZv9Fk8bOm3ICOR_rDeHxyrRd0u6TNWJeCKePl7SeuwJOm6LBE9fN4f7RxPkn036feigrU9JJeQDQOW6sAkk9jzeti_9Nmxo$
------------------------------------------------------------------------
The information contained in this e-mail is confidential and/or
proprietary to Capital One and/or its affiliates and may only be
used solely in performance of work or services for Capital One.
The information transmitted herewith is intended only for use by
the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby
notified that any review, retransmission, dissemination,
distribution, copying or other use of, or taking of any action in
reliance upon this information is strictly prohibited. If you have
received this communication in error, please contact the sender
and delete the material from your computer.
_______________________________________________
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
