Re: [OAUTH-WG] How does OAuth harm privacy ?

[Warren Parad <[e-mail]>]

👏

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Mon, Mar 1, 2021 at 5:27 PM Jim Manico <[e-mail]> wrote:

> Denis,
>
> > With OAuth, the RS must have a prior relationship with the AS (which is
> not scalable).
>
> I do not see this as a real problem since in almost every use case the RS
> and AS are the same provider. If they are not the same provider I would
> suggest federation (OIDC) as opposed to delegation (OAuth2) which are
> completely different standards even though they are built on top of the
> same framework.
>
> > When the client calls the AS, the AS is able to know which is the RS and
> then is in a position to know which end-user is likely to access which RS.
>
> If you are using OAuth2 for delegation and the RS and AS are not the same
> provider then I feel you are using the wrong standard/framework.
>
> > When furthermore *token introspection* is being used
>
> Token introspection in my opinion needs to go away. First of all it kills
> performance. It also leaks unnecessary information as you rightfully point
> out. I prefer to migrate to JWT's for this purpose and distribute public
> keys for services that need to verify tokens. Again, the  token
> introspection defeats the point of statelessness, a critical feature of
> modern services.
>
> > Since the access tokens are considered to be opaque to the clients (and
> hence to the end-users), a client is not supposed
> to verify which privileges have effectively been inserted into an access
> token, in particular whether a unique identifier
> that would allow the RSs to correlate the accounts of their users has been
> maliciously added into every access token.
>
> In typical OAuth2 delegation flows, the user is agreeing to give a client
> a certain level of access to their account at the AS/RS provider. The user
> allows this. The user is saying I am giving ClientX access to features A, B
> and C in my account. Of course the client needs to see this in order to
> effectively communicate to the RS/AS provider. I do not see this as a
> problem. The user is specifically allowing it.
>
> Denis, please keep going. I am not a top tier expert I am still learning.
> I would love to keep this conversation going.
>
> Respectfully,
>
> - Jim Manico
>
>
> On 3/1/21 10:29 AM, Denis wrote:
>
> Hello Jim,
>
> Since you dared to raise the question: "*How does OAuth harm privacy* ?",
> I need to respond. I changed the tile of the thread accordingly.
>
> With OAuth, the RS must have a prior relationship with the AS (which is
> not scalable). When the client calls the AS,
> the AS is able to know which is the RS and then is in a position to know
> which end-user is likely to access which RS.
>
> When furthermore *token introspection* is being used, the AS is in a
> position to know exactly when an end-user
> is performing an access to every RS. Some people would say that the AS is
> able to act as *Big Brother*.
> While this might be acceptable within a single domain (i.e. all the users,
> ASs and RSs belong to the same organization
> or company), this is a serious concern if/when used in general over the
> Internet in a multi-domain case.
>
> Since the access tokens are considered to be opaque to the clients (and
> hence to the end-users), a client is not supposed
> to verify which privileges have effectively been inserted into an access
> token, in particular whether a unique identifier
> that would allow the RSs to correlate the accounts of their users has been
> maliciously added into every access token.
>
> In your email you wrote:
>
> I don’t see how moving from handing your creds over to a third party to
> OAuth2 workflows, harms either privacy or security.
>
> I hope that the facts mentioned above will allow you to see that OAuth
> does harm the user's privacy.
>
> Denis
>
>
> Il 01/03/2021 15:13 Jim Manico <[e-mail]> <[e-mail]> ha
> scritto:
>
>
> How does OAuth harm privacy?
>
> I think you are analyzing the matter at a different level.
>
> If you start from a situation in which everyone is managing their own
> online identity and credentials, and end up in a situation in which a set
> of very few big companies (essentially Google, Apple and Facebook) are
> supplying and managing everyone's online credentials and logins, then [the
> deployment of] OAuth[-based public identity systems] is harming privacy.
>
> Centralization is an inherent privacy risk. If you securely and privately
> deliver your personal information to parties that can monetize, track and
> aggregate it at scale, then you are losing privacy.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, [e-mail]
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>