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
