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

2021-03-01 Thread Warren Parad 
đź‘Ź

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Mon, Mar 1, 2021 at 5:27 PM Jim Manico  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   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, 
> open-xchangevittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> __

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

2021-03-01 Thread Jim Manico 

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  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, Open-Xchange
vittorio.bert...@open-xchange.com    
Office @ Via Treviso 12, 10144 Torino, Italy


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Jim Manico
Manicode Security
https://www.manicode.com

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] How does OAuth harm privacy ?

2021-03-01 Thread Denis 

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  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, Open-Xchange
vittorio.bert...@open-xchange.com    
Office @ Via Treviso 12, 10144 Torino, Italy


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth