OpenID 2.0 for Google Accounts is going away | Hacker News Reader

OpenID 2.0 for Google Accounts is going away

support.google.com

79 pointsluu21 comments

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

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

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

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

OpenID, OAuth, and the like have just made things more confusing for both devs and users alike, IMHO. Wasn't it supposed to "unify" things and make it easier and safer for everyone?

For example:

- a site might offer to login via Facebook, but I'm afraid to in case my friends' Facebook news feeds get spammed.

- I want to offer an easy login for my users, but which OAuth provider do I pick? Which OAuth, OpenId thing am I supposed to use? They all look the same! But different!

We used OpenID 2.0 for our internal auth system to provide SSO across domain names and we just finished implementing OpenID Connect. I can't even begin to describe how much of a difference there is between the two, OpenID Connect is completely painless while OpenID 2.0 fought us every single week.

Can't wait to migrate everything over to Connect instead.

According to the page at https://developers.google.com/accounts/docs/OpenID#shutdown-..., the first user-visible warnings appeared in November 2014 (unless disabled by the site operator). 6 months is not an unreasonable timeline to make some minor adjustments to your auth system to make it OpenID Connect compatible (from a quick glance at the migration page, it basically required adjusting the auth URL and adding a few extra params).

I don't know if you can call it a minor adjustment. More like implementing a new method, like adding facebook connect. It's a completely different api, also you have to register an app on cloud.google.com. At least they still provide backwards compatible tokens.

OpenID Connect is an entirely separate protocol from OpenID 2.0. Essentially, it's an extension of OAuth2, which is difficult to implement correctly on your own. Libraries are available for most languages for it, though.

OAuth 2 is not difficult to implement as a consumer.

Have you read the specs? Getting it "working" is trivial, but to guarantee security there are a lot of considerations and checks you must or should do that are easily overlooked.

Pretty much all of the security considerations are factors for the provider and not the consumer. Consumers should use validated TLS and encrypted storage, but beyond that consumers have more to worry about keeping their own application secure.

So this seems to affect… a lot of services. I'm surprised it's not getting more coverage. Unless this message appears when it doesn't need to, a massive number of prominent services rely on this, such as StackOverflow (if you attach it to a google account obv.).

Stack Overflow has already addressed this issue: http://meta.stackexchange.com/q/244367/61654.

Oh I see, it comes up for me because I specifically use OpenID through my domain. That's just my problem then.

Just to clarify: this is OpenID 2.0, not OAuth 2.0. OpenID never really went anywhere with consumers, most of whom had no idea what their openID URL was (I think mine had an 8 in it). HN got rid of it years ago.

Reply on news.ycombinator.com