Re: [OAUTH-WG] Tenancy in OAuth
Jaap Francke <Jaap.Francke@mendix.com> Wed, 13 January 2021 10:10 UTC
Return-Path: <Jaap.Francke@mendix.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 E49FF3A0C04 for <oauth@ietfa.amsl.com>; Wed, 13 Jan 2021 02:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mendix.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 TwEVtNQCUr59 for <oauth@ietfa.amsl.com>; Wed, 13 Jan 2021 02:10:25 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80051.outbound.protection.outlook.com [40.107.8.51]) (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 3C00D3A0C85 for <oauth@ietf.org>; Wed, 13 Jan 2021 02:10:15 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sh/oj2PGLB4OAyuGMb7MWRK/+yNmTR1Pp12dDFsWxxTAlJsiAMfoUj9s//zGOtLdvGrLo5D+2D74n9Czm4zvgxfWVMilXeLgBXLxDvY/zkftBVO7cFgLG/uaePh+huCOZbhleVJIhtHGDrUBBF4AR0UAU6XHfbJcjjKzU3qwGYiw2qutkQloaJKibpy8qvtg0TIs1c/FBCKQmGvbC89C6jqlxS1K6p0PMLyDr9DKiyG/DvuPOW8kVOWzCLghgCCR/ejU6YUHcEZh/UGykGXidogaNcypYYPDyn+OXdmXO9eldgDEfMpZKlueX00GOvR4ox4UjBaIqv0ZePnmQ6TMQA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TH8Dvn1HGX/hWOMzvmSTxHYTTQDRQEPIOMpPkyPBzmk=; b=aA38hwviFakiUnIOUEBAGJtHeppamw41JSSLGrVx5N8miBMXz4vElv7yKzby7BgCsFtXCmsEtiWsWo+h5NXXTOGzM4cmU0RQQIq1h5Gphm+MYNitjctFYQS6ToDxlD4+ALHp6u17LzdGttR83fYDNJurGGc5Kyue80F5oC36TaQuW4o7v0Qtb5FjT/n9YI1BUW7x9QKVpgo7EDdHeFhZ1LrUuubZqdBE2f4knMlVyVlHoeiRm6+yHLf7A7nLwueUOqRG9cEG86bZZ4p0wGEoXgBmqI/siscQURojuJ+KO4Xjdhf0seux2KqeObNVDSwiu3CedJEBGkoCPB0pFkcC2A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mendix.com; dmarc=pass action=none header.from=mendix.com; dkim=pass header.d=mendix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mendix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TH8Dvn1HGX/hWOMzvmSTxHYTTQDRQEPIOMpPkyPBzmk=; b=Mpab2FUkMfcdNIri+qYA6GsXMSh8xY6UZnMypeJTLvo4Cr23YzjGzGuvdxjhh6cZzFJW9lqhfxJG8Jw1Cwyvav73xNwnwOD11fJxs6+zDlkDg82ktRonGd9EJ8DN+8CDoXewTgTWXxWpaAI3+dFu+JtCqJrPLion1oJDlc8d6Os=
Received: from AM0PR06MB4180.eurprd06.prod.outlook.com (2603:10a6:208:7a::24) by AM4PR0601MB2132.eurprd06.prod.outlook.com (2603:10a6:200:47::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.12; Wed, 13 Jan 2021 10:10:12 +0000
Received: from AM0PR06MB4180.eurprd06.prod.outlook.com ([fe80::489b:ed4b:779c:37e]) by AM0PR06MB4180.eurprd06.prod.outlook.com ([fe80::489b:ed4b:779c:37e%5]) with mapi id 15.20.3742.012; Wed, 13 Jan 2021 10:10:12 +0000
From: Jaap Francke <Jaap.Francke@mendix.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Tenancy in OAuth
Thread-Index: AQHW6ZRH9/k3PuSDgEq0Kqp8ugdsjA==
Date: Wed, 13 Jan 2021 10:10:12 +0000
Message-ID: <35A2B178-B99F-4EBB-A2A8-A386183682C5@mendix.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mendix.com;
x-originating-ip: [86.84.216.78]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aedb06d5-9836-4d02-7925-08d8b7ab6a76
x-ms-traffictypediagnostic: AM4PR0601MB2132:
x-microsoft-antispam-prvs: <AM4PR0601MB21321C0DD37F292E696D84FCE4A90@AM4PR0601MB2132.eurprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2276;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VztivfesjRwcxqumh6VRzzvWE7TfZo/LIp13NrQLYsLMweu99yYoigcKg/4q+abSYekqJbyIQ7ArxYCWxsZkWjJZ35NTf5ALk575roJLBwFLWrIAePoxEP70EILEO9h3tkVy3v5PuE9fQv4pKesquxZ869yPagl5dd50hl48+s7CMefxn4ZpCFuMBUPVaGjZAQ2pNGz36zYl9dyOKsVQ4/gcVGj761hEiCk3Yjiyt29nzpfbUaeLKF8mbALpPapPXi0ns/A9EhR2k/XaOOhS7L9c/4mPJmtZbz2Aj4wpzp/Ei9QXP3qvbakYzR/KWW84J+ATjB/AglsAJ2RLW2qwpcT4i7cen9MYBllqmi8n+etgpwU7CQnmF5EtGpukdgy6dJmJk2TYpYRa8LJjy9yPxOS6+paVDnY+xSOVuAmpR6kUQa5YM58OOWSdt7Wgx8jJXJcUnMJSFvPXRSv0mTVXMm6CBIYOVaPb8Xpfeg1iw9rZFGU8XWbLGjjPbHR7GIBzqW1gKyuvHRRV1f/OdU94WA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR06MB4180.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(346002)(39850400004)(136003)(376002)(186003)(53546011)(83380400001)(478600001)(4743002)(71200400001)(8676002)(45080400002)(76116006)(26005)(33656002)(966005)(66946007)(3480700007)(7116003)(316002)(86362001)(8936002)(6916009)(64756008)(66446008)(66476007)(5660300002)(66556008)(6506007)(6512007)(30864003)(2616005)(2906002)(36756003)(6486002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: uwG6qhs914ZeJKKRkEfgUKaDNkieeEuX5dGqzChPS5LY41STkw5h3CElTnNOUs0aaMA4XX0/oMcboRQ7JbboMRQ3IBppqIEp1Wb57vZPSzvi+WVKOYxW0auj8W+kXUQdcA3fsRIjXA+W556xw+GPl8nBMeXzhna4gJw9cCWytvvkRZXpatmyqyW6na3Vi0qmKAoe8CMSXs2exPqDVzvwh76UnXhbmJq5NyucOAwwt478X38YtRBpHPgg7uSJgSV9txi2siv7b4WWsFXQfMuKovhXGk+nGuXElgS5+goHwgm2xrihD3H6NkGiuClPyJEh0X40w5NTJVOVW9NFuSRWMSBtPoWHRVuudYnCtAOtIl1ELrlZcnX1hsLt7iLqSm5o8aiVSwfu9rOx0PBREgdHj1ySidrHuLped4vhktinWX249WHBdEIaMGNv1OxyxiYz+AwLkiBUlZZC3LF6cXUqYwm3gvlwjHpn5eiGQbvP0IhMvh1aj1I+OmBW7GDpVF9IqLL1igyaOyhYIWbhKc21r0rQ24z2dPNj/xMzxLHhyTTT7QwzdOGjpzvZeEitql6nJiP4wGK27mATjh3j3EoYwGg0x+DhLtBay9BDd5VxWXegQzVW4jAZGvPxpAK7g3w3zgT1+qM/TzaoDkotjj8A8sl9TnVqTHCMa4o7i0eW/BZsH08CyReQRNEuR9zwFFWuXFu9yIqtLvY77/TU8tUKVQm46SZwySr2HCMwNldkz3PMYGWBevDn2ZyS88aqNKUpoWl182xV3MGtBCBOoXKxCQAEvONxzH8pFj1KKRd2NezWSZe1bADkS+o32oHO/fIVBqqXWBMHE2df/GYWvGfSwPyvs1Zm/M/fh56f8eI6qGp49UCrnNmGaDq49Pqvzqc7xnFTtYmrNwlTaO6D1aO5GLs/BbKs0w2GBdwWDSimFtxh4+/9bZcBwzi0LILRjpMoiD3M0nBhMeM27RrKbqpiva6/DSgAl7Q8Ra4BGiUHdnQ3TfZT9+uDP1sC/a/3ACZu
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <6594D3310310204C8C7B7D4D901E76C6@eurprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: mendix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR06MB4180.eurprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aedb06d5-9836-4d02-7925-08d8b7ab6a76
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2021 10:10:12.5525 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b4e3c78d-8e3b-46d8-bc56-5540da23ba4d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pwqVLXTcQv/lXEMW83RHcEsJ/iR+I+E1w0/amzRCu9+kkt3aiCdGOqQ5ZigjlzyMaTJ2EqaQjeFO2YLgSkrxFQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0601MB2132
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/VZtf670jiAc_9JQogxdjcklOO3Q>
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: Wed, 13 Jan 2021 10:10:28 -0000
Thanks Justin and Vladimir for your guidance! The resource indicator approach seems to have the best fit for my use case. It addresses my coarse/mid-grained use case, without bringing the complexity of the fine-grained RAR approach. Encoding the tenant into scope values remains an option as well. Ensuring the token validation is implemented properly is indeed a point of attention. Meanwhile I've been looking into OAuth/OIDC specs for client registration. It may also be useful to extend the client's metadata with 'resource' to bind the specific client to a specific tenant(s). Would that make sense to you as well? Great feedback, kind regards, Jaap On 12/01/2021, 23:10, "OAuth on behalf of oauth-request@ietf.org" <oauth-bounces@ietf.org on behalf of oauth-request@ietf.org> wrote: Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zNVyuy2avEEWtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3D&reserved=0 or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Tenancy in OAuth (Justin Richer) 2. Re: Tenancy in OAuth (Vladimir Dzhuvinov) ---------------------------------------------------------------------- Message: 1 Date: Tue, 12 Jan 2021 16:13:26 -0500 From: Justin Richer <jricher@mit.edu> To: Jaap Francke <Jaap.Francke=40mendix.com@dmarc.ietf.org> Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Tenancy in OAuth Message-ID: <E3DE5ED2-7506-4090-A32A-F3D4AE797DF5@mit.edu> Content-Type: text/plain; charset="utf-8" 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8707&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8707&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3D&reserved=0> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-rar-03&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-rar-03&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&reserved=0> 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 <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmendix.com%2F&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nPKjePc%2B%2B8TuM4zuCG6ZU2XNsPmJxu5WidmCHz9E%2BSU%3D&reserved=0> > <image001.png> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mendix.com%2F&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7HQ1qe32Hc9QcYNVY8667ufxmLz7DDWCYA8mhsKSHVo%3D&reserved=0> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zNVyuy2avEEWtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zNVyuy2avEEWtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3D&reserved=0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Foauth%2Fattachments%2F20210112%2F19aa55e2%2Fattachment.htm&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1QzWSxQ4esCxjTI6f5mb7CPFxiYs9aCdVcHIyEnuwMk%3D&reserved=0> ------------------------------ Message: 2 Date: Wed, 13 Jan 2021 00:10:01 +0200 From: Vladimir Dzhuvinov <vladimir@connect2id.com> To: oauth@ietf.org Subject: Re: [OAUTH-WG] Tenancy in OAuth Message-ID: <cc41517f-f732-0d6f-95f3-64bb7fcdf24e@connect2id.com> Content-Type: text/plain; charset="utf-8" Hello Jaap, Justin made a good overview of the available OAuth facilities when dealing with multiple resource servers or resource server tenants. If you have control over the resource server, i.e. the token validation is going to happen in one place, then you have plenty of freedom to find out what will work best for you, semantically and in terms of available OAuth server. In cases when the resources are left to implement the token validation on their own my preferred approach is to encode the resource server identity (tenant) into the scope values. Access is defined in one place and I don't have to worry about the developer accidentally forgetting the "resource" or "aud(ience)" check. Vladimir On 12/01/2021 23:13, Justin Richer wrote: > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8707&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3D&reserved=0 > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-rar-03&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&reserved=0 > > 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 >> <mailto: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 <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmendix.com%2F&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FAM7a7iH5y8E6ETAg%2BAmrNh3WnAuBiOZ%2FEBhikqOFxI%3D&reserved=0> >> >> *<image001.png>* <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mendix.com%2F&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MaqH3Kv4ob56Lp28m9g2idLEXiLlpkkwt4QctYTAiqg%3D&reserved=0> >> *?* >> ? >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8%2Fk%2BVZS9e%2B%2FCwEwSVo7nqivuwjdg3Jy48x6awkBTxV0%3D&reserved=0 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8%2Fk%2BVZS9e%2B%2FCwEwSVo7nqivuwjdg3Jy48x6awkBTxV0%3D&reserved=0 -- Vladimir Dzhuvinov -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Foauth%2Fattachments%2F20210113%2F136b5985%2Fattachment.htm&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0dJ3kYyigdBtbUDNhwRipAzwj5urzkKKLCzquGTy7vY%3D&reserved=0> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Foauth%2Fattachments%2F20210113%2F136b5985%2Fattachment.p7s&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BqMHy4Z%2FkjRCeyE8UHgUuqtm8D%2FLwPd2HffEmhiVfcs%3D&reserved=0> ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8%2Fk%2BVZS9e%2B%2FCwEwSVo7nqivuwjdg3Jy48x6awkBTxV0%3D&reserved=0 ------------------------------ End of OAuth Digest, Vol 147, Issue 6 *************************************
- [OAUTH-WG] Tenancy in OAuth Jaap Francke
- Re: [OAUTH-WG] Tenancy in OAuth Justin Richer
- Re: [OAUTH-WG] Tenancy in OAuth Vladimir Dzhuvinov
- Re: [OAUTH-WG] Tenancy in OAuth Jaap Francke
- Re: [OAUTH-WG] Tenancy in OAuth Vladimir Dzhuvinov