Hacker News Reader

Comment by mikesname | Hacker News Reader

I must say, having switched from Google OpenID 2.0 to Google OAuth2.0 for authentication on our site I raised an eyebrow when I belatedly read on Homakov's 2013 blog[1] that OAuth2.0 was never intended for authentication, only authorization for certain discrete resources. At least with Stack Exchange doing it I'm in good company, but - if Egor is correct - it raises the question what's really a good choice for authentication nowadays.

[1] http://homakov.blogspot.com/2013/03/oauth1-oauth2-oauth.html

View on HN

Mozilla Persona is the right approach to authentication. Unfortunately, Mozilla sucks more at marketing than Microsoft did in the late 90s and Persona got near null interest from developers that weren't already concerned by the very real dangers of OAuth and the uprise of Facebook/Twitter authentication.

Persona is still there. It's still maintained, despite getting no funding, but that doesn't mean developers can't pick it up. If you are interested in authentication, learn about it. Implement it. Support it. Convert people.

https://www.mozilla.org/en-US/persona/ https://developer.mozilla.org/en-US/Persona

Plus, if you use Persona, your users get automatic Google OpenID Connect (and others).

Howso?

Persona is fantastic, highly, highly recommended. If you have a web app, please look into integrating Persona, at least as an alternative.

Are there any client libraries available for Persona? Ruby, Python, JavaScript, C#?

Edit: Found this - https://developer.mozilla.org/en-US/Persona/Libraries_and_pl...

It's true, OAuth 2.0 alone isn't intended to be used for authentication. Think of it this way: An OAuth access token is often described as being analogous to a valet key — anybody bearing the valet key can unlock whatever it is that the valet key unlocks, but this says nothing about the bearer of the valet key.

Google now uses an OAuth 2.0 extension called OpenID Connect. This introduces an entity that's analogous to a referral letter [1], the ID token. It's basically a little string of encoded (possibly encrypted, possibly signed) JSON containing 'claims' about the authentication state of the end user. The client application can then validate that token to confirm to its satisfaction that the authentication happened for some particular user — and that the ID token was created for it and not some other application.

[1] http://nat.sakimura.org/2011/05/15/dummys-guide-for-the-diff...

OpenID Connect would be a good choice for authentication. Which is really just OAuth 2.0: http://openid.net/connect/

Macaroons are pretty interesting: https://air.mozilla.org/macaroons-cookies-with-contextual-ca...

Reply on news.ycombinator.com