From an OAuth perspective, there isn’t much here - I can’t log into GitHub or stack overflow with OAuth, I need extensions such as those provided by OpenID Connect (or something more bespoke in Github’s case).
From a general standards perspective, this would be more implementation guidance for relying parties who want to support multiple authentication mechanisms. In this case, a relying party should not register a new third-party authentication provider against a user account without authenticated user consent - unless it is being done as part of an account creation process itself. Or to put it more simply - outside of streamlining account creation, these third-party authentication providers are just authentication mechanisms chosen by the user - you have no basis of trust to accept any other attributes/claims given, and trust the assertion of authentication solely because _your_ user has indicated it is how they want to be able to log in. For a more trusted setup, such as a first-party authentication system or second party (such as the authentication system chosen by a SaaS tenant), you can rely on this sort of data quite a bit more. For example, an authentication assertion might be sufficient to provision an entirely new user account in a SaaS on-demand. This sort of implementation is fairly common, and means that I can authenticate into the service whether the email accounts are the same or different (or if the authentication provider withholds email address altogether). My impression was that stack overflow already acted according to this hypothetical guidance. > Anyone read this topic or could tell if there is a better place to adress > this? OpenID Connect might be an appropriate place for additional relying party guidance. The broader issue is that someone implementing a bespoke system like GitHub or Facebook integration is not going to look to OpenID Connect for implementation guidance. -DW > On Aug 9, 2023, at 2:05 PM, mfulz <mf...@olznet.de> wrote: > > > 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
