Hacker News Reader

Comment by teh | Hacker News Reader

OpenID has been on its way out for a while. It's being replaced by OpenID Connect [1] so this is not bad news, but a good reminder in any case!

[1] http://openid.net/connect/

View on HN

Practically, openID is being replaced by oauth. A decade ago authentication and authorisation were quite separate concepts. This has been replaced with a realisation that 'being authorised to use a particular account' (Google Account, Twitter, FB, etc) is sufficient to prove ownership of that account and therefore identity.

OpenID Connect is based on OAuth.

OK. What else does OpenID Connect get me, vs asking for a limited-scope oauth?

Basically, OpenID Connect is for federated authentication, and OAuth2 is for delegated authorization. I like Vitorrio's explanation: http://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-s...

Even though its community maintained these days, Mozilla Persona was a great authentication mechanism with federation support. I loved using it. A pity it failed to get traction.

This gives me the creeps. Authorisation and identification are not the same. If you use 'Login with X' you're giving X access to all your accounts. That's not just third party attestation of your identity. It's kind of like saying a passport is what gives you access to your home country... in reality your status as a citizen is what gives you that right, the passport is merely a convenience.

Authorization of a null permission is effectively the same as authentication, though. I think the GP's point was that authz implies authn, even if the set of permissioned authz'd for is empty.

Edit: see reply below, I think I misunderstood the parent post.

> If you use 'Login with X' you're giving X access to all your accounts.

That's definitely not correct. You are giving X to access only whatever scopes you allowed, on a single account.

Here's an example of just 'userinfo'. Click this and see what it asks for: https://accounts.google.com/AccountChooser?service=lso&conti...

Per the screen, it only allows:

" - View your full name, profile picture and profile URL"

" - View any publicly available information on your Google+ profile (if you have one or create one in the future)"

It can't see your photos, see your contacts, read your email, post G+ messages, or anything else you didn't authorise.

I think you are misunderstanding what he is saying. If you use Google to prove your identity to every website you use, you are giving Google access to all of those websites.

Yeah you're right, see my other reply.

I believe the intended meaning was that if you login at randomsite with google, google has access to your randomsite account, as opposed to randomsite having access to your google account.

Thanks. Actually now I re-read what he wrote, although it wasn't obvious, he did convey that.

So, in other words:

- RandomWebApp lets users log in with Google.

- A RandomWebApp user has a Google account, and allows RandomWebApp to oauth against his Google account.

- Since Google issue the access token used for RandomWebApp, Google could conceivably access RandomWebApp on the user's behalf.

That's a legitimate concern.

If you can reset your password with access to your gmail account, then Google can already do this, yes?

That's not a very quiet way of doing it, though. Even if they hid the reset email from me, I'd be locked out of my account, which could raise suspicions.

It's a legitimate concern, but there's no way around it with third-party authentication. You always need to trust your identity provider, don't you?

I don't see how separating identification and authorization conceptually helps. You have to trust your identification provider, in any kind of a federated or multi-party system. (Ie, a system where you can log into your google account and get access to another system, whether using OpenID 1.0, 2.0, OAuth, whatever).

Having Google impersonate me is not what I fear, it is so obviously evil.

Having Google hurt me is what I fear.

Google's use of its identity service is not on an equal footing as RandomWebApp's. Having a Google+ identity means accepting its TOS for a specific list of services provided by Google[1].

Violating the TOS (eg, by misusing, even accidentally, one of Google's services (think DMCA and ContentID mis-tagging fair use material, or even by not providing the name that the US has registered for you)) means losing your identity. That has definitely happened to at least a dozen of people I know.

Additionally, Google enforces identity in the context of a company based in the US. Whatever obligations it has in front of its government, and whatever weaknesses the government finds, will allow misusing your identity, even when Google itself isn't being evil.

[1] Excerpt from the TOS:

> Our Services are very diverse, so sometimes additional terms or product requirements (including age requirements) may apply. Additional terms will be available with the relevant Services, and those additional terms become part of your agreement with us if you use those Services.

https://www.google.fr/intl/en/policies/terms/regional.html

That was actually understood a decade ago as well and was part of the conversation that led to OpenID and OAuth. It was suggested close to a decade ago that they both merge efforts and they have both struggled to find their place. Development on this scale just lags a bit behind, specially when the community around it is so fragmented and opinionated.

I'm a tad confused... To be authorised is great, but authentication must first happen surely? Authorisation says I can access x, but authentication says I am who I say I am!

Being authorized to use a particular account is still seperate from proving who I am. I have visions of going to the Pentagon and I say "Hi, President Obama here, give me access to all your intelligence data" and the analysts saying "Certainly sir! You have top authorisation, here is all the data". :-)

Actually, that would work better at a bank. "Hi, I'm Donald Trump, give me a million dollars from my loose change account, thanks!"

Technically you don't authenticate using OAuth, you just have a secret token - which is proof you own the account. If you wanted to stretch your analogy, you could say a check from Donald Trump is just an authorisation.

OAuth definitely does authenticate though (hence the name).

The auth on 'oauth' is for authorization - see https://tools.ietf.org/html/rfc6749

Your first sentence is totally correct though.

Great question. Think of it as "Hi, I'm an individual who has an oauth access token for President Obama's userinfo.me scope. The only person who can authorise this is President Obama".

Hope that helps.

In fact, unlike previous OpenID protocols, OpenID Connect is a profile of OAuth 2.0.

The conflation of authorization with authentication is an accident and a mistake. They are still quite separate concepts. Authentication is about verifying identity. Authorization is about privileges afforded a given identity. Access control models usually depend on some form of upstream authentication.

The third-party authorization flows provided by OAuth are not intended to establish or verify a user's identity. Their purpose is to extend a user's access to a third-party in a limited way without sharing passwords.

Social Sign-in is an accident of 3-Legged OAuth and its use for this purpose is considered a very weak form of authentication.

OpenID Connect takes the best ideas from preceding identity protocols and incorporates them into OAuth flows, giving the best of both worlds.

More information on all of the above here: https://github.com/christiansmith/anvil-connect/wiki/Referen...

You've said limited scope authorisation is weak authentication, but you haven't said why in your post.

Can anyone advocating OpenID connect give a single sentence explanation of why people (developers and users) would want to use it vs limited scope oauth?

Do you have any suggested good reads about the topics ?

Reply on news.ycombinator.com