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