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

Warren Parad <wparad@rhosys.ch> Mon, 01 March 2021 18:20 UTC

Return-Path: <wparad@rhosys.ch>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8818C3A20CC for <oauth@ietfa.amsl.com>; Mon, 1 Mar 2021 10:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBglpSm9hm1l for <oauth@ietfa.amsl.com>; Mon, 1 Mar 2021 10:20:48 -0800 (PST)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F3C3A20CA for <oauth@ietf.org>; Mon, 1 Mar 2021 10:20:48 -0800 (PST)
Received: by mail-il1-x129.google.com with SMTP id f10so15027303ilq.5 for <oauth@ietf.org>; Mon, 01 Mar 2021 10:20:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4s9kLMpIwIu0Rx9/6447CZKgowwscDz5ju4PBw2T9zw=; b=E37GJbaY5maa4kM0b5TguiODg/R4E6Sat0Q0RBDtjk4WCe4k/eDusiKJEIMR6YaoTb Ck8q5rZxhQblOpiod60+iAtMRUpSWb8KGlr0j8Xwx5V73qfoIMzWZwGpq1iyoTJznl8f zDa/SHy8QxSwjDmaZbpD0cHK5K9MKQiAb4fjIRRGrzbkpGYRHmrvs3fDFrlcfBL8C7v6 uHA6qj0lYpU3/DV65tat+gOPaeBL2LRocgE96tGyxsxaRuMA+Lt54ZsfxhuqzivjJaV6 Cs2LplXTAalfDwzCD5HyuG+TsWZj1cVAGqu0K4o4YIuAWQvrMsjiqQ96KJ8KuMl9Mi2B EcbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4s9kLMpIwIu0Rx9/6447CZKgowwscDz5ju4PBw2T9zw=; b=RfmLH0FL+wk5dpXLqSNkUhqUTtni/a/ipLKDCcf0gQYKtrVrmAmoke87LE4nQLsUTy KFSz9e9sVRDEW4IgyoUJLgENqJe4ziVPBGd+1Ilhbc4ucw0U4rTuDWNopHRoDcLCQRiF tHCQQaS2RJcIq2WFiGcMts0pb14wgZtRapQ5vpw/VJQq9qhOc54cGv4kTN/gLt5Mfo+C +qTIPdCRXEsIfmraCXeyMLw5VJTtlYryrGa+JUEv22K5gyORN5MStDf32Cr8gURghYTP aNVBz0Pf3jgoUSe0FM8wJBgQMC0qo87nDp6ySm+scR67hs6UmvBhjZZ/vDXHwA/lZI0s 0DxQ==
X-Gm-Message-State: AOAM5320LnjF8EYAXSWzbZj0/+GttyZpdD5eKuEsvg6b9qS4o3xnTcZI NxVkX4Lf9zck64f89O4nfO7NCQ2Bq8qpuF1Ft0xV
X-Google-Smtp-Source: ABdhPJzVq1/aBepnKv6W0F/V+OaEXjH7BwxZen8Y8+QT451V4pQdoOHdgb/sCb552Z8OaZ3VMJR9urcibhWQGy5LF9w=
X-Received: by 2002:a92:c6ca:: with SMTP id v10mr14477604ilm.195.1614622846347; Mon, 01 Mar 2021 10:20:46 -0800 (PST)
MIME-Version: 1.0
References: <CWXP265MB0566C4B21C45E760B1BFED7FC29A9@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM> <EF14E7AC-CA19-44EE-9EC6-D21A81ECA756@manicode.com> <1016085528.105908.1614610785506@appsuite-gw1.open-xchange.com> <5681917b-2496-7965-3047-773f46522ed2@free.fr> <69bc987a-06e4-6808-7204-d5ee6264900a@manicode.com>
In-Reply-To: <69bc987a-06e4-6808-7204-d5ee6264900a@manicode.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Mon, 1 Mar 2021 19:20:35 +0100
Message-ID: <CAJot-L0i167tCRgE3moVbfsbCdXT-DWkAtk52yC4wHtxGk1dwA@mail.gmail.com>
To: Jim Manico <jim@manicode.com>
Cc: Denis <denis.ietf@free.fr>, IETF-Discussion Discussion <ietf@ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000034075905bc7dadd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/j9OTV88g7m8MFCh_uD-4goZ7Ffc>
Subject: Re: [OAUTH-WG] How does OAuth harm privacy ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 18:20:51 -0000

👏

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 <jim@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 <jim@manicode.com> <jim@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.bertola@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
>