
Ask HN: What should I use for authentication (WebID, OpenID, Password)? - danieka
Hi HN,<p>I&#x27;m writing an web app for kicks that appeals to quite a small niche. I don&#x27;t expect MAU to ever go above a thousand. I&#x27;m still dedicated to providing a good service though.<p>At one point I intend to add login functionality and was wondering what the &quot;best&quot; mechanism is.<p>Login with social networks is probably the easiest for users. But I&#x27;m a bit kooky and don&#x27;t want to support Facebook&#x27;s hegemony so that&#x27;s out of the question.<p>Basically I see three alternatives.<p>1. Login with password. Another account to keep track of, but it works.<p>2. WebID. github.com&#x2F;solid&#x2F;solid appears to be going with WebID, but it&#x27;s not exactly simple. And it requires that the user understands what a private key is and why they shouldn&#x27;t lose it.<p>3. OpenID. Is this the technology of the future? From what I&#x27;ve read adoption is slowing down and the largest independent OpenID provider closed down a while ago (MyOpenID).<p>So, is there a method of authentication that is both open, decentralized and simple for the end-user?
======
hdhzy
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
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
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.

------
djsumdog
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.

------
phsource
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.

------
spangry
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/OpenIDConne...](https://developers.google.com/identity/protocols/OpenIDConnect)

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.

------
dmlittle
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)

------
cestith
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.

------
pstan26
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-
blocksta...](https://blockstack.org/blog/serverless-sign-in-with-blockstack-
auth)

------
1ba9115454
Go with 1. Login with password you'll hit the maximum number of users that
way.

------
nailer
oauth to the person's email account. Authorisation to use someone's email is
sufficient authentication.

~~~
stephenr
Doesn't that assume their email host supports oauth?

------
leecarraher
Sqrl "squirrel" looks promising. Probably need passwords too though.

~~~
leecarraher
[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

