Re: [OAUTH-WG] Tenancy in OAuth

Justin Richer <jricher@mit.edu> Tue, 12 January 2021 21:13 UTC

Return-Path: <jricher@mit.edu>
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 07CAF3A1229; Tue, 12 Jan 2021 13:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 J6n9ktnW1IQG; Tue, 12 Jan 2021 13:13:29 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A733A1227; Tue, 12 Jan 2021 13:13:28 -0800 (PST)
Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10CLDQVX001228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jan 2021 16:13:27 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <E3DE5ED2-7506-4090-A32A-F3D4AE797DF5@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD5D422C-DD86-4AE0-B212-C6D0AA04CE0C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 12 Jan 2021 16:13:26 -0500
In-Reply-To: <A643E85A-B4B0-437B-AB76-80BF3F795983@mendix.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
To: Jaap Francke <Jaap.Francke=40mendix.com@dmarc.ietf.org>
References: <A643E85A-B4B0-437B-AB76-80BF3F795983@mendix.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0hx-KDIRNptnqDzkIeYtyXIwHmc>
Subject: Re: [OAUTH-WG] Tenancy in OAuth
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: Tue, 12 Jan 2021 21:13:31 -0000

Hi Jaap,

There have been a number of efforts to address this kind of thing in the OAuth world. You can definitely use a special scope to encode this value, which has the benefit of fitting into the implementation limitations of nearly all OAuth systems out there. The “resource” parameter can also be used for the kind of thing, and it gives you a bucket that’s separate from “scope” so that you can keep the latter available for describing the API itself:

https://tools.ietf.org/html/rfc8707 <https://tools.ietf.org/html/rfc8707>

There’s also the Rich Authorization Request (RAR) draft that this group is currently working on, which provides a multi-dimensional way to describe access. It’s more complex than scopes, but it boils down to having JSON objects describe the elements needed. In this case you might put the API bits into the “actions” and “datatypes” fields, and put the tenant information into the “locations” field. I believe there are people using it in exactly this way today:

https://tools.ietf.org/html/draft-ietf-oauth-rar-03 <https://tools.ietf.org/html/draft-ietf-oauth-rar-03>

There are also some historical efforts to address this, including an “audience” and a (completely separate) “aud" parameter, but AFAIK neither of these have been raised to standard or even to common practice, and so I wouldn’t recommend it. I currently have a project to migrate a system that’s currently using one of these onto RAR.

 — Justin

> On Jan 12, 2021, at 11:20 AM, Jaap Francke <Jaap.Francke=40mendix.com@dmarc.ietf.org> wrote:
> 
> Hi,
>  
> I’m looking into the topic of tenancy. A multi-tenant service can be considered as an OAuth Resource Server managing resources of different tenants.
> An AS makes authorization decisions and communicates these using scopes, so one way would be to ‘encode’ the tenant into the scope values.
> Another line of thought is to somehow bind/restrict an acces-token to a certain tenant, leaving the set of scopes being used more static.
>  
> My question is whether this has been a topic that has been addressed in the OAuth working group? Any common practice or draft?
> Thanks in advance for your replies.
>  
> Kind regards,
>  
> Jaap Francke
> Product Manager Identity
> +31(0)641495324
> mendix.com <http://mendix.com/>
> <image001.png> <http://www.mendix.com/>
>  
>  
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>