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
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 <jim@xxxxxxxxxxxx> 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.bertola@xxxxxxxxxxxxxxxx Office @ Via Treviso 12, 10144 Torino, Italy
_______________________________________________ OAuth mailing list OAuth@xxxxxxxx https://www.ietf.org/mailman/listinfo/oauth
-- Jim Manico Manicode Security https://www.manicode.com
