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

[1]: https://www.chromestatus.com/feature/4952188392570880

[2]: https://www.chromestatus.com/feature/5097603234529280

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

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". :)

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.

I don't understand what benefit a __Secure prefix for cookie names has, that just setting the secure flag doesn't?

From their links:

This feature adds a set of restrictions upon the names which may be used for cookies with specific properties. These restrictions enable user agents to smuggle cookie state to the server within the confines of the existing "Cookie" request header syntax, and limits the ways in which cookies may be abused. In a nutshell: `__Secure-` cookies have to have the `Secure` flag, and `__Host-` cookies have to have `Path=/`, can't have `Domain`, and might require `Secure` (depending on the setter).

From: https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/

Cookie prefixes make it possible to flag your cookies to have different behavior, in a backward compatible way. It uses a dirty trick to put a flag in the name of the cookie. When a cookie name starts with this flag, it triggers additional browser policy on the cookie in supporting browsers.

The __Secure- prefix makes a cookie accessible from HTTPS sites only. A HTTP site can not read or update a cookie if the name starts with __Secure-. This protects against the attack we earlier described, where an attacker uses a forged insecure site to overwrite a secure cookie.

I would consider a browser that allows a cookie with a secure flag to be overwritten from a http page buggy, and thus the solution would be simply enforcing the secure flag in a same way.

What legitimate use is there for overwriting a secure cookie with a non secure one?

Yes, exactly. After setting a cookie server usually cannot check if it is secure or not but using this prefix on modern browsers guarantees to server that the cookie is certainly secure. Of course it works only in modern browsers but it's part of defense in depth.

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.

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.

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

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

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.

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

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.

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

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

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

Doesn't that assume their email host supports oauth?

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