4 ms·

Ask HN: What should I use for authentication (WebID, OpenID, Password)?

• phsource 10y ago
  I think the most open (and perhaps "easiest for users") is still just using email and password. It's the baseline, and unless social features or real-world identity verification is a core part, email/password is available as a signup method. It's also open (two text strings), decentralized (you can use whatever password manager you want), and simple (people have been using it for ages). So before implementing anything else fancy, I'd highly recommend doing email/password first.
• djsumdog 10y ago
  I still have an independent openid server, but the only sites that still take OpenID are StackOverflow and Python's Pypi. Slashdot and Woot use to support it, but have since removed it. Freecode.com used it, but it's gone now. My suggestion is as follow: always allow signups via e-mail/registration. If I go to a site and the only options are "Login with Facebook/Google/Twitter," it's not worth my time. I never used those walled gardens as identity providers. There are a number of people who do login with their social network, so if you want to get that segment of the population to try your app, you do need to support login via 3rd party providers. Usually two should be enough (Facebook, Twitter, Google). Under the surface, most providers use either OAuth or OpenID. Most web frameworks have plugins that support a variety of authentication types. Pick a framework with a good auth plugin that shows frequent commits and a large userbase. You want something that is actively developed, so if security problems are found, they can be patched quickly. I totally understand not wanting to allow FB logins. If your audience is mostly the HackerNews types, then you could authenticate with GitHub as well.
• pstan26 10y ago
  I think what you are looking for is here with Blockstack: open, completely client-side and decentralized, and for the user you don't even need to use a password...experience is like login with facebook, except without supporting the hegemony :) https://blockstack.org/blog/serverless-sign-in-with-blockstack-auth https://blockstack.org/blog/serverless-sign-in-with-blocksta...
• nailer 10y ago
  oauth to the person's email account. Authorisation to use someone's email is sufficient authentication.
  • stephenr 10y ago
    Doesn't that assume their email host supports oauth?
• leecarraher 10y ago
  Sqrl "squirrel" looks promising. Probably need passwords too though.
  • leecarraher 10y ago
    https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
• hdhzy 10y ago
  User name and password plus hardware token. Currently only U2F meets the requirements (supported in Chrome and Firefox with an extension) but soon enough Web Authentication [0] (successor of U2F) will be natively supported by all major browsers. The benefit of this approach is that you don't need complex passwords (4 digit pin will suffice) as the hardware token provides strong security. For bearer tokens use secure, httponly cookies that have names starting with __Secure- [1]. Check Origin header to protect against CSRF. Optionally consider using token binding [2] so that cookies cannot be exported at all. [0]: https://www.chromestatus.com/feature/5669923372138496 https://www.chromestatus.com/feature/5669923372138496 [1]: https://www.chromestatus.com/feature/4952188392570880 https://www.chromestatus.com/feature/4952188392570880 [2]: https://www.chromestatus.com/feature/5097603234529280 https://www.chromestatus.com/feature/5097603234529280
  • danieka 10y ago
    That's actually quite cool. The use case in the spec indicates a really smooth user experience while providing great security. https://www.w3.org/TR/webauthn/#use-cases https://www.w3.org/TR/webauthn/#use-cases I'm definitely going to keep track of this standard, but as I understand it no browser has released it yet? Edit: I didn't properly read your reply, so disregard everything after "quite cool". :)
    • hdhzy 10y ago
      Edge has Web Authentication support but only a draft version. The generated keypair is stored in TPM so after authentication credentials are basically bound to user's device. Web authentication is indeed quite cool. You can also drop passwords altogether and just rely on the token and the username (caveat: someone knows your username and physically steals your token is a threat) or even drop usernames at all! As U2F tokens generate new keypair per origin you'd only need the token to authorize. Of course if someone steals it and tries to login to your site... It's like physical key.
  • stephenr 10y ago
    I don't understand what benefit a __Secure prefix for cookie names has, that just setting the secure flag doesn't?
• cestith 10y ago
  Don't confuse OpenID 1 and 2 with OpenID Connect. OpenID Connect 1.0 is a particular set of narrowly defined workflows on top of OAuth 2.
• spangry 10y ago
  I have to admit I'm a little confused about the relationship between OpenID and OpenID Connect. At any rate, OIDC is a restricted, but still standards conformant, profile of OAuth 2 designed specifically for authentication: Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself. (http://openid.net/connect/ http://openid.net/connect/) I can't find any direct assurance on the OpenID Connect website that a conformant OIDC implementation will by definition be compatible with a compliant OAuth2 implementation, although I suspect this is due to the open-ended nature of the OAuth 2 standard (i.e. I'm not sure if you could confidently say any particular implementation of OAuth2 would be compatible with another implementation). FWIW, you can implement an OIDC 'relying-party' directly on top of google's social auth OAuth 2 endpoint, if I'm reading this correctly: https://developers.google.com/identity/protocols/OpenIDConnect https://developers.google.com/identity/protocols/OpenIDConne... Unless much has changed in the past year or so, it's also very easy to do a relying-party implementation, which I think matches your scenario. For example, I wrote a (probably insecure) relying-party implementation straight from the spec in a bit less than a day, and I'm not a programmer by trade. It worked when tested against one of the django OIDC libraries floating around out there, which came as a bit of a shock. This might suggest the standard is 'tight' enough to ensure interoperability between independent implementations. Then again, it's only one data point so YMMV.
• 1ba9115454 10y ago
  Go with 1. Login with password you'll hit the maximum number of users that way.
• dmlittle 10y ago
  If you don't want people to have to keep track of another password you could implement a sans password login system. 1. In the login form, ask for an email. 2. When a user inputs an email, send an authenticated link to their email. This link contains an authentication key that can be used to perform a one time login (or several) to an account associated with the corresponding email. 3. If a user has logged out or needs to login from another device, simply enter your email again and receive a new authentication link (or use the email you received in the past). 4. If a user logs out, invalidate all the previously generated login URLs. Notion[1] uses this system and I like it [1] https://notion.so https://notion.so