đź‘Ź 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 <j...@manicode.com> 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 <j...@manicode.com> <j...@manicode.com> 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 > > _______________________________________________ > 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
