3 ms·

There are 2 major problems that must be addressed: 1. Using OAuth to sign-up often means disclosing private data you can (and would normally prefer to) keep se

There are 2 major problems that must be addressed: 1. Using OAuth to sign-up often means disclosing private data you can (and would normally prefer to) keep secret if you go the bare e-mail sign-up way. E.g. contacts list, exact date of birth, etc. - This is why I (as a user) stopped using OAuth for new accounts. Kind of the same used to apply to e.g. Android apps. I mean the "give an app all the permissions it wants or gtfo" anti-pattern which ought be abolished. The user should be allowed to continue after denying/revoking access to any (but absolutely essential for the very function) data silently or manually specifying whatever values they want. 2. It isn't always easy to decouple an OAuth-based account from the social network account, especially in case you loose access to the latter. - This is why I (as a user) migrated all OAuth-based accounts I had to the good old e-mail way.

mattlutze 6y ago
These are two great discussions to raise in the working group communications. If you go through the link that they've shared, you can sign up directly and participate in the conversation about how they architect the v3 rebuild.
namanaggarwal 6y ago
Your first point is actually not a OAuth issue, but how the provider designed it. You can build an OAuth provider that don't need to disclose anything(not even email)
- qwerty456127 6y ago
  As a user I don't really care about the way they build it. I care about the spec to deny them forcing me to disclose the data. I once tried to sign-up with Google an it asked me to allow (with no option to deny but continue) to share my specific personal details. I've cancelled and never used this technology ever since. I didn't have to specify the same details (which Google was going to share) when signing-up with an e-mail address. The spec should discourage sharing details beyond necessary, prevent any details from being shared silently and ensure user can always deny and continue.
  - magicalhippo 6y ago
    But there's nothing in the spec that requires you to disclose that data to begin with. And there's nothing they could write in the spec to deny that besides a perfunctory "please don't do that" which companies could ignore without consequence.
    - fuzzy2 6y ago
      Sure they could. What you allow or deny would be enforced by the identity provider. The relying party simple would not receive the data and could not access it. However, that’s really about OpenID, not about OAuth.
      - freeone3000 6y ago
        These are treated as permissions in the AAD OAuth model. Your issue seems to be with the Google and Facebook implementations, not the spec.
        qwerty456127 6y ago
        The spec could say something like "a client may ask for extended information but can't demand it unconditionally and must gracefully handle situations when access to particular fields is denied".
        freeone3000 6y ago
        This is anticipated by scope requested by the client being able to be ignored by the authorization server. This appears in the AAD flow for the user as a list of toggles. The application has to handle the case where the scope is less than what is listed - this is all in section 3.2. Actually defining what data or permissions is bound to what scope is rightfully beyond the goals of the specification.
        BHSPitMonkey 6y ago
        But that's already possible, right? The problem is that you can't make _everything_ optional, or else the user can deny everything and the application then has to tell the user "You denied X, but we really need it to proceed. Try again...", which is a definitively worse experience than having the grant request say "here's what this app is asking for".
- jrockway 6y ago
  Is this even a provider issue? If an application asks for scopes=[profile] then the OAuth provider has two choices -- categorically deny it, or ask you to authorize it. They all ask you to authorize it, and you can say no, and then the app doesn't work because the developers decided that you can't use their app unless you give them your profile information. The app could easily ask you to check a checkbox next to each scope, and then write separate code for each combination of checkboxes. They decided not to do that because it's probably not worth your business if you don't want to give them full access. (Honestly, I click a lot of things on HN that ask for way too many scopes, and then I close the window and forget what it was. But the calculation was done -- they don't need me as a user or customer. I can live with that.) I guess what people want is an IDP that will give applications fake data when you deny a scope. But no application developer wants to deal with that complexity, so they'd never integrate a provider that does that. (They probably moved away from email+password because of all the fake emails that people provide.) On the other hand, it's mandatory for iOS apps to use Apple's sign-in which auto-generates a fake email address for you. So I suppose some progress is being made. (I have an iPhone but I've never seen this supposedly mandatory OAuth provider. I only know about it from reading HN. So maybe it doesn't actually exist? I have no idea really.)
  - btown 6y ago
    Auto-generating a single-use profile, or letting you choose a pseudonym, is absolutely a compromise that more identity providers should implement.
  - namanaggarwal 6y ago
    Yes it is really provider issue. Apple implemented it and so can any other provider. I also don't think people want an IDP that provides fake data when you deny a scope. That's a bad implementation IMHO. When you say no that means you don't authorize access for that scope, not that send fake data. Applications should deal with it.
    - jrockway 6y ago
      You are fighting conflicting constraints, though, and that's the underlying problem. Application developers won't use an IDP that protects user data. They want that data, that's why they wrote their app! Because nobody would use such an IDP (at least not without being forced to in order to be on a large platform), nobody will write such an IDP. I'm actually working on an open-source IDP in my spare time, and to me this sounds like something to seriously consider doing right. I appreciate the idea and the discussion. I doubt anyone in the real world will care, though. (Sometimes you need to get the early adopters that do care about these things, though :)
asah 6y ago
Create a new/throwaway email account. Granted this is annoying.
pharaohgeek 6y ago
OAuth isn't solely about social networks. There are a number of corporations that use it for delegated authorization. A financial aggregator and a bank, for example. A large number of SaaS providers support G-Suite logins for enterprise customers as well.
- oaiey 6y ago
  Oauth2 / OIDC is essentially next to SAML the only serious identity provider protocol in the single sign on space. Ignoring LDAP and Active Directory for now.
fyfy18 6y ago
What you are talking about is OpenID Connect, not OAuth. It does use OAuth 2.0 under the hood, but they are two separate protocols. OAuth is an authorization protocol. It can be used (for example) to give Facebook access to your Flickr photos without having to give out your Flickr username and password to Facebook or share API tokens, and have a standardized way to revoke access when you realise Facebook scraped all your private photos.
- ownagefool 6y ago
  Actually, OpenID Connect is an SSO product. Whilst it can be used to federate your auth to other providers, you're probably thinking of OpenID, which is "social login".
  - ForHackernews 6y ago
    No, parent commenter is correct: OpenIDConnect is an extension protocol that adds a user-authentication (user metadata) layer on top of OAuth 2, which is a bare authorization protocol (access tokens are opaque and don't say anything about the user). Besides the similar names, OpenIDConnect has virtually nothing to do with the older OpenID protocols. Old-style OpenID has been deprecated and removed by almost all web properties today (e.g. https://meta.stackexchange.com/questions/307647/support-for-openid-ended-on-july-25-2018 https://meta.stackexchange.com/questions/307647/support-for-...)
    - ownagefool 6y ago
      I'm not really sure I understand the is complaint then? So the problem the OP is worried about is a SaaS provider using OIDC to federate to corp SSO and leaking data such as that within the id_token? Otherwise, what's the leak here?
      - tingletech 6y ago
        iiuc, the complaint is still valid -- it's just that OIDC is what causes the attributes to be in the flow, not OAuth that causes the attributes to be in the flow.

mattlutze 6y ago

These are two great discussions to raise in the working group communications. If you go through the link that they've shared, you can sign up directly and participate in the conversation about how they architect the v3 rebuild.

namanaggarwal 6y ago

Your first point is actually not a OAuth issue, but how the provider designed it. You can build an OAuth provider that don't need to disclose anything(not even email)

qwerty456127 6y ago
As a user I don't really care about the way they build it. I care about the spec to deny them forcing me to disclose the data. I once tried to sign-up with Google an it asked me to allow (with no option to deny but continue) to share my specific personal details. I've cancelled and never used this technology ever since. I didn't have to specify the same details (which Google was going to share) when signing-up with an e-mail address. The spec should discourage sharing details beyond necessary, prevent any details from being shared silently and ensure user can always deny and continue.
- magicalhippo 6y ago
  But there's nothing in the spec that requires you to disclose that data to begin with. And there's nothing they could write in the spec to deny that besides a perfunctory "please don't do that" which companies could ignore without consequence.
  - fuzzy2 6y ago
    Sure they could. What you allow or deny would be enforced by the identity provider. The relying party simple would not receive the data and could not access it. However, that’s really about OpenID, not about OAuth.
    - freeone3000 6y ago
      These are treated as permissions in the AAD OAuth model. Your issue seems to be with the Google and Facebook implementations, not the spec.
      - qwerty456127 6y ago
        The spec could say something like "a client may ask for extended information but can't demand it unconditionally and must gracefully handle situations when access to particular fields is denied".
        freeone3000 6y ago
        This is anticipated by scope requested by the client being able to be ignored by the authorization server. This appears in the AAD flow for the user as a list of toggles. The application has to handle the case where the scope is less than what is listed - this is all in section 3.2. Actually defining what data or permissions is bound to what scope is rightfully beyond the goals of the specification.
        BHSPitMonkey 6y ago
        But that's already possible, right? The problem is that you can't make _everything_ optional, or else the user can deny everything and the application then has to tell the user "You denied X, but we really need it to proceed. Try again...", which is a definitively worse experience than having the grant request say "here's what this app is asking for".
jrockway 6y ago
Is this even a provider issue? If an application asks for scopes=[profile] then the OAuth provider has two choices -- categorically deny it, or ask you to authorize it. They all ask you to authorize it, and you can say no, and then the app doesn't work because the developers decided that you can't use their app unless you give them your profile information. The app could easily ask you to check a checkbox next to each scope, and then write separate code for each combination of checkboxes. They decided not to do that because it's probably not worth your business if you don't want to give them full access. (Honestly, I click a lot of things on HN that ask for way too many scopes, and then I close the window and forget what it was. But the calculation was done -- they don't need me as a user or customer. I can live with that.) I guess what people want is an IDP that will give applications fake data when you deny a scope. But no application developer wants to deal with that complexity, so they'd never integrate a provider that does that. (They probably moved away from email+password because of all the fake emails that people provide.) On the other hand, it's mandatory for iOS apps to use Apple's sign-in which auto-generates a fake email address for you. So I suppose some progress is being made. (I have an iPhone but I've never seen this supposedly mandatory OAuth provider. I only know about it from reading HN. So maybe it doesn't actually exist? I have no idea really.)
- btown 6y ago
  Auto-generating a single-use profile, or letting you choose a pseudonym, is absolutely a compromise that more identity providers should implement.
- namanaggarwal 6y ago
  Yes it is really provider issue. Apple implemented it and so can any other provider. I also don't think people want an IDP that provides fake data when you deny a scope. That's a bad implementation IMHO. When you say no that means you don't authorize access for that scope, not that send fake data. Applications should deal with it.
  - jrockway 6y ago
    You are fighting conflicting constraints, though, and that's the underlying problem. Application developers won't use an IDP that protects user data. They want that data, that's why they wrote their app! Because nobody would use such an IDP (at least not without being forced to in order to be on a large platform), nobody will write such an IDP. I'm actually working on an open-source IDP in my spare time, and to me this sounds like something to seriously consider doing right. I appreciate the idea and the discussion. I doubt anyone in the real world will care, though. (Sometimes you need to get the early adopters that do care about these things, though :)

asah 6y ago

Create a new/throwaway email account. Granted this is annoying.

pharaohgeek 6y ago

OAuth isn't solely about social networks. There are a number of corporations that use it for delegated authorization. A financial aggregator and a bank, for example. A large number of SaaS providers support G-Suite logins for enterprise customers as well.

oaiey 6y ago
Oauth2 / OIDC is essentially next to SAML the only serious identity provider protocol in the single sign on space. Ignoring LDAP and Active Directory for now.

fyfy18 6y ago

What you are talking about is OpenID Connect, not OAuth. It does use OAuth 2.0 under the hood, but they are two separate protocols. OAuth is an authorization protocol. It can be used (for example) to give Facebook access to your Flickr photos without having to give out your Flickr username and password to Facebook or share API tokens, and have a standardized way to revoke access when you realise Facebook scraped all your private photos.

ownagefool 6y ago
Actually, OpenID Connect is an SSO product. Whilst it can be used to federate your auth to other providers, you're probably thinking of OpenID, which is "social login".
- ForHackernews 6y ago
  No, parent commenter is correct: OpenIDConnect is an extension protocol that adds a user-authentication (user metadata) layer on top of OAuth 2, which is a bare authorization protocol (access tokens are opaque and don't say anything about the user). Besides the similar names, OpenIDConnect has virtually nothing to do with the older OpenID protocols. Old-style OpenID has been deprecated and removed by almost all web properties today (e.g. https://meta.stackexchange.com/questions/307647/support-for-openid-ended-on-july-25-2018 https://meta.stackexchange.com/questions/307647/support-for-...)
  - ownagefool 6y ago
    I'm not really sure I understand the is complaint then? So the problem the OP is worried about is a SaaS provider using OIDC to federate to corp SSO and leaking data such as that within the id_token? Otherwise, what's the leak here?
    - tingletech 6y ago
      iiuc, the complaint is still valid -- it's just that OIDC is what causes the attributes to be in the flow, not OAuth that causes the attributes to be in the flow.