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

Jim Manico <jim@manicode.com> Mon, 01 March 2021 16:26 UTC

Return-Path: <jim@manicode.com>
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 82CBF3A1F1B for <oauth@ietfa.amsl.com>; Mon, 1 Mar 2021 08:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com
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 CHYACDLOLmKI for <oauth@ietfa.amsl.com>; Mon, 1 Mar 2021 08:26:15 -0800 (PST)
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 7E8123A1F1E for <oauth@ietf.org>; Mon, 1 Mar 2021 08:26:15 -0800 (PST)
Received: by mail-qv1-xf2e.google.com with SMTP id x13so2416652qvj.7 for <oauth@ietf.org>; Mon, 01 Mar 2021 08:26:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=AB3kQyi4FFK6ieyyGhYJYeI0HjsvrdZsH1E2GkzNxB8=; b=W10twG/3kClcj24iajNFAzbCXtdFSLfz7QRP5beFPkxjk78M/8MfJl+Yw9ZpYfF3Dy oRxQ/hBCR+cdWl0A732bXkVimJx4IzmcHU+RN57bEJ4p4p1qSxUwxHMTReHTJSrVLovb 4uWX5R3zbIc5AwpFBi3RL53Gx5absL+/f6Gxx/mrkoiUPPUZzfRLFdd5zEo8CH9ot8wi KVQzvhng/v4HcaSoLzSyEBIxXq0+Y4WLB2IJ9ieg3+1eO1/1Qn2RghqM1byJkwLWzcBd d+dZylM4bboKAP/7XSdkqeMwLKTuK+rnTLKuuIxYB2qRCJGXJkxsXvxOH2Qppp4FVs4S R21w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AB3kQyi4FFK6ieyyGhYJYeI0HjsvrdZsH1E2GkzNxB8=; b=sDP2AeWfv+ugRnw4BYaR8grDZ4HTdratzRIGCKk7OghRSbZdZTQis+S6cnWGQeI7fk eLPdachfswYuDHXJtndz1jtGJdP+RVKusr1DWGVxIsLOBFFabllNpHgJjJPnFZijB87a VKY1hA1247CM9XkOeALNGtTUBzhhLsAj3CxLAWacll2wTXiTYERvoQJToltQMsAPg9S4 CLf/MmeBmNBnIAzh5ySM/7IUpSmuai/YA8uGc4W1cWFAdlxqvb0opky4LuM6q9BNqvto 8p+zQyVT0k6QVPMrznBSLt3YIaU+nv/BTt/32Cbp5ZRjRyQN5OrsfhghbGWk1n5e6bC1 /1Zg==
X-Gm-Message-State: AOAM5304Y0NW0xA22LjnSgmyB8I0k/5TPakWeqBi4ctedw9CEvWlGXe2 IULEC5RqewqOY5aydWe3uWyUUUXelroCnA==
X-Google-Smtp-Source: ABdhPJw+fgOYkcyfoqvUO25hVq9WQ/+6es3VuK0uDdyIjZqmqCh02/w88dhk9Hpf2q7KgXhHnNR/MQ==
X-Received: by 2002:a0c:8ec7:: with SMTP id y7mr15399663qvb.9.1614615973115; Mon, 01 Mar 2021 08:26:13 -0800 (PST)
Received: from macbook-pro.lan (c-71-62-187-187.hsd1.va.comcast.net. [71.62.187.187]) by smtp.googlemail.com with ESMTPSA id x14sm11615933qtq.47.2021.03.01.08.26.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Mar 2021 08:26:12 -0800 (PST)
To: Denis <denis.ietf@free.fr>
Cc: IETF-Discussion Discussion <ietf@ietf.org>, oauth@ietf.org
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>
From: Jim Manico <jim@manicode.com>
Message-ID: <69bc987a-06e4-6808-7204-d5ee6264900a@manicode.com>
Date: Mon, 1 Mar 2021 11:26:11 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <5681917b-2496-7965-3047-773f46522ed2@free.fr>
Content-Type: multipart/alternative; boundary="------------9C524D708A0E9192F9C549B6"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/byauX33tZMH028WbdSo2hXXWsWc>
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 16:26:17 -0000

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> 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@open-xchange.com  <mailto:vittorio.bertola@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