5 ms·

Understanding OAuth 2.0 and OpenID Connect

72 points by abd12 8y ago

billfruit 8y ago
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.
- Boulth 8y ago
  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.
  - cdcarter 8y ago
    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.
    - WorldMaker 8y ago
      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.
    - zie 8y ago
      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".
      - BrandoElFollito 8y ago
        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)
        zie 8y ago
        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.
        BrandoElFollito 8y ago
        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.).
    - eikenberry 8y ago
      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.
      - deathanatos 8y ago
        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.)
    - ams6110 8y ago
      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.
- bryanlarsen 8y ago
  StackOverflow OpenId login is being discontinued: https://meta.stackexchange.com/questions/307647/support-for-openid-ends-on-july-1-2018 https://meta.stackexchange.com/questions/307647/support-for-...
  - cdcarter 8y ago
    OpenID and OpenID Connect are different and practically unrelated technologies. StackOverflow will still have social login.
- ibejoeb 8y ago
  There was support for openid initially. It was removed years ago. Not sure if there was a statement about it.
UncleMeat 8y ago
> 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.
- idubrov 8y ago
  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.
  - rdegges 8y ago
    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.
    - idubrov 8y ago
      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.
- rdegges 8y ago
  I'd actually add that implicit should never be used for mobile app unless you have no backend whatsoever.

72 points by abd12 8y ago

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.

Boulth 8y ago
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.
- cdcarter 8y ago
  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.
  - WorldMaker 8y ago
    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.
  - zie 8y ago
    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".
    - BrandoElFollito 8y ago
      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)
      - zie 8y ago
        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.
        BrandoElFollito 8y ago
        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.).
  - eikenberry 8y ago
    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.
    - deathanatos 8y ago
      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.)
  - ams6110 8y ago
    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.
bryanlarsen 8y ago
StackOverflow OpenId login is being discontinued: https://meta.stackexchange.com/questions/307647/support-for-openid-ends-on-july-1-2018 https://meta.stackexchange.com/questions/307647/support-for-...
- cdcarter 8y ago
  OpenID and OpenID Connect are different and practically unrelated technologies. StackOverflow will still have social login.
ibejoeb 8y ago
There was support for openid initially. It was removed years ago. Not sure if there was a statement about it.

UncleMeat 8y ago

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

idubrov 8y ago
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.
- rdegges 8y ago
  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.
  - idubrov 8y ago
    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.
rdegges 8y ago
I'd actually add that implicit should never be used for mobile app unless you have no backend whatsoever.