Per https://openid.net/specs/openid-connect-core-1_0.html
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect is an identity protocol. Request: Who is this user? Response: Here is an identifier and maybe other claims about the user. OAuth is an authorization protocol. Request: Can I access the user's stuff? Response: Yes, here you go. The confusion happens when some of the stuff that is being accessed about the user are claims about the user that the resource server is making. Note that the resource server is making the claims, not the AS / OP. On Thu, Aug 10, 2023 at 1:54 PM Hans Zandbelt <hans.zandb...@openidc.com> wrote: > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
