Understanding OAuth 2.0 and OpenID Connect | Hacker News Reader

Understanding OAuth 2.0 and OpenID Connect

blog.runscope.com

72 pointsabd1224 comments

> The Implicit flow is designed specifically for mobile apps or client side Javascript apps where embedded credentials could be compromised. The mechanics are simple in that the application redirects the user to the Identity Provider to authenticate, the IdP passes back token(s), and the application uses it according to the scopes it has.

Do not use Implicit Grant in mobile apps unless interacting with an app provider (and even then, Implicit Grant still has some major footguns if you are using it for authn, which most people are). It was absolutely not "designed specifically for mobile apps." If you are talking to the browser you cannot ensure that the access token is delivered to the right place and access tokens are not bound to the relying party. If you are using the access token for authn like suggested here, you let malicious apps impersonate your users.

If you are using a mobile app and performing OAuth through the browser, use Authz Code flow with PKCE.

I wonder if the same recommendation (use Authorization Code Grant flow plus PKCE instead of Implicit Grant) should be made for SPA (single page applications), too.

Unfortunately, most SPA apps don't have a server side backed and thus cannot benefit from the additional security that the Authorization Code flow provides.

They are in the same category as mobile apps in that respect, no? Both of them are "public clients" in terms of OAuth 2.0.

I'd actually add that implicit should never be used for mobile app unless you have no backend whatsoever.

Even then you should still use authz with pkce. At the very least nobody else should be able to get your access token. For some workflows this is all the guarantee you need.

It even says so on the official website ( https://oauth.net/2/grant-types/implicit/ ) - astonishing that they can't get this right. Maybe says something about the product?

Yep. I'm fairly concerned about an identity management company publishing this information.

Author here -

Entirely agree and we recommend using Auth Code+PKCE whenever possible. This post is intended to be the first of a few starting with the base spec. In the next one, I plan to go over the RFCs for JWT, Revocation, Inspection, PKCE, the AppAuth pattern, and probably a few others.

Thanks for the note though.

Thanks for the shoutout to AppAuth (https://appauth.io). It’s our 20% project at Google.

For someone rather new to HN, is there any reason HN, of for that matter reddit do not support logging in with third party accounts? Stackoverflow for example does support them, and whatever may be their downsides, they are mighty convenient.

I'm definitely not part of the team that works on HN but my impression is that HN strives to be as simple as possible. I actually like the current minimalistic username+password scheme. No activation email, no captchas. What's wrong with that? Not every site needs a NASCAR-like login screen.

Generally, because managing passwords (both for the end user and for the server) is difficult, and there's no reason to get into the identity management business if you don't absolutely need to.

I understand the reasoning behind this, since it's hard to get right, but if we offload all of our logins to Facebook,Google and friends, they suddenly get WAY more information about us. You as site author are giving them access to all of your users, and you as a user of the site are giving them access to where you wander on the Internet.

Plus if a breach happens on Facebook or Google, then the hackers get EVERYTHING including access to your site (as a site author).

So there are definitely downsides to doing social login(s) as well, and it's not as clear cut as just "let Google and friends do it for me".

What WAY more information do they get?

They know that I use the site and (to some extend) when.

I am under the (possibly false) poison that the risk is to let the requesting site (HN here) request to much data from, say, Google (my age, shoe size and whatever they store about me)

They get that you use site X (and y,z, and q too) , when you use those sites, and where you were when you logged in from(i.e. your IP, browser info, etc).

For one site, not a huge issue maybe, unless it's ilovemesome<insert something disgusting here>.com

But add this up across many, many sites, and they suddenly get loads and loads more information to sell ads to you with.

Yes, this is true - but at least in the case of Google this is peripheral compared to what they have though my browsing (search, email, etc.).

The main problem is you still need to support password based auth unless you want to lock out part of your user base that doesn't have an account with the supported providers or doesn't want their login activity tracked by one of the providers.

and doesn't wish to setup their own provider.

I get that that is definitely not an easy thing to do, but an OpenID implementation doesn't have to force users to log in through some major social network, and I feel like your statement asserts that.

(but even with that addendum, I agree, you'll probably still end up wanting to support password based login as a service provider. But as a user, I greatly appreciated not having to constantly get my password manager to meet some random list of requirements.)

It's just unfortunate that OpenID 1/2 or Persona didn't succeed. The "NASCAR" badging problem of OpenID Connect is a poor solution that doesn't scale.

A wish for a decentralized solution that actually had user traffic so we could all DROP COLUMN password FROM user.

I would agree, only I don't see what HN does as "indentity management." There's no mapping to a real person or identity. It's just a local login. HN doesn't care who you are in real life.

StackOverflow OpenId login is being discontinued: https://meta.stackexchange.com/questions/307647/support-for-...

OpenID and OpenID Connect are different and practically unrelated technologies. StackOverflow will still have social login.

There was support for openid initially. It was removed years ago. Not sure if there was a statement about it.

Reply on news.ycombinator.com