5 ms·
This requires your users to trust whichever OAuth providers you decide to integrate with. Sometimes, the set of "trusted OAuth providers" for your users is {}.
by sarciszewski 11y ago
This requires your users to trust whichever OAuth providers you decide to integrate with. Sometimes, the set of "trusted OAuth providers" for your users is {}. What then?
> 99% of the websites that "require" me to create an account and log in don't need to store primary credentials for me
Why are you giving them valuable credentials? Give them a throw-away password (password managers are great for this).
- oliwarner 11y agoI meant OpenID. I literally couldn't see I was saying the wrong thing. Everything you say about OAuth is true. I'm an idiot. I'm sorry for getting so blue in the face. A hybrid between the two (common OAuth-style endpoints and any OpenID endpoint) is the best solution for everybody.
- oliwarner 11y agoYou don't integrate with a provider. You implement the protocol and let your users supply a URL. Layering on popular alternatives (Facebook, Google, etc) help, but use the Stack Exchange model. Let users do what they want to do. That way users can be their own oAuth providers if they want.
- ngrilly 11y agoI thought that Stack Exchange was using OpenID?
- sarciszewski 11y agoMy question was: "What if your users don't trust any of the existing providers on Earth?" It's hard to make a blanked recommendation like that, even for "only 99%" of websites. Neither you, nor the person building the website, has any insight into who the website's users trust. Offer OAuth2 as an alternative to passwords: Great move. Only offer OAuth2 and don't let people create an account: Questionable.
- oliwarner 11y agoI did answer. They can host their own. I don't understand why they would trust <crappy forum owner> over a dedicated authentication storage place but that's their choice. And yes, there is also every possibility to offer direct credentials, per the Stack Exchange model (they host their own oAuth server and allow simple registrations).
- sarciszewski 11y ago> I don't understand why they would trust <crappy forum owner> over a dedicated authentication storage place but that's their choice. What if <crappy forum owner> happens to be a security engineer, and <crappy forum> happens to be Silk Road 13? The trust decisions people make are situational and nuanced. OAuth is great if that's where people invest their trust. Otherwise, you're outsourcing it for the user to a company they might fear.
- oliwarner 11y agoAgain. The user picks who they authenticate with. You (the site owner) get no say in the matter. You aren't outsourcing it to any one company.
- sarciszewski 11y agoNo, you're saying "which of this limited set of companies are you going to authenticate with" instead. If you don't want to be guilty of taking users' agency away from their own trust decisions, you need to do one of two things: 1. Let every website on the Internet potentially be an OAuth provider. 2. Make OAuth optional. If you follow option #2, then this article is still relevant because you need to handle passwords securely.
- oliwarner 11y agoYour first paragraph is like saying using email is forcing somebody to use one of a "limited set of companies". It's nonsense. Again, if they don't like what's on offer they can host their own, just like email!. They can hire a company like yours to host their credentials with as many layers of security as they want. The user has ultimate choice. Secondly, every website on the Internet is potentially an OAuth provider. Not to mention that I have —on multiple occasions here— suggested that websites that consume OAuth should also provide it (like Stack Exchange).