[OAUTH-WG] Token Chaining Use Case

Justin Richer <jricher@MIT.EDU> Thu, 26 March 2015 18:31 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651551A90BE for <oauth@ietfa.amsl.com>; Thu, 26 Mar 2015 11:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 14E8vSWs-v9P for <oauth@ietfa.amsl.com>; Thu, 26 Mar 2015 11:31:28 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C526A1A9241 for <oauth@ietf.org>; Thu, 26 Mar 2015 11:31:24 -0700 (PDT)
X-AuditID: 12074424-f79f56d000000da5-5e-5514507ad7c0
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 5F.A4.03493.A7054155; Thu, 26 Mar 2015 14:31:22 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t2QIVLoE024957 for <oauth@ietf.org>; Thu, 26 Mar 2015 14:31:22 -0400
Received: from dhcp-b47c.meeting.ietf.org (dhcp-b47c.meeting.ietf.org [31.133.180.124]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2QIVJ6l028297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <oauth@ietf.org>; Thu, 26 Mar 2015 14:31:21 -0400
From: Justin Richer <jricher@MIT.EDU>
X-Pgp-Agent: GPGMail 2.5b6
Content-Type: multipart/signed; boundary="Apple-Mail=_EB1D3C9A-55CC-4C8C-981D-8668655EA882"; protocol="application/pgp-signature"; micalg=pgp-sha256
Date: Thu, 26 Mar 2015 13:31:17 -0500
Message-Id: <D0E09E09-A803-427A-ACA9-D9E3F3EF31E5@mit.edu>
To: "<oauth@ietf.org>" <oauth@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUixCmqrVsVIBJqsGS/hcXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseXTUeaCT8oVy990sjUwzpTtYuTkkBAwkbh3aB0rhC0mceHe erYuRi4OIYHFTBJren8yQjjHGCW2N/5khXBeMklceL+WDaSFTUBVYv7KW0wQ7VISTa+PgXUw C0xhlDj69D87SEJYQEHi08dtYEUsQA1vmi6wgNi8AlYSLz5dAqsREVCXWHP+JxNE3EBi7qkv QDYH0FB5iZ5N6RMY+WYhGzsLSRmIzSygLbFs4WtmCFtTYn/3chYIW15i+9s5UHFLicUzb0DF bSVu9S2A6rWTeDRtEesCRo5VjLIpuVW6uYmZOcWpybrFyYl5ealFuuZ6uZkleqkppZsYQQHO 7qKyg7H5kNIhRgEORiUe3h/9wqFCrIllxZW5hxglOZiURHk3uomECvEl5adUZiQWZ8QXleak Fh9iVAHa9WjD6guMUix5+XmpSiK8bh5AdbwpiZVVqUX5MGXSHCxK4rybfvCFCAmkJ5akZqem FqQWwWRlODiUJHjt/IEaBYtS01Mr0jJzShDSTBychxglOHiAhvuB1PAWFyTmFmemQ+RPMSpK ifN+9QNKCIAkMkrz4HphiekVozjQW8K8j0GqeIBJDa77FdBgJqDB5/L5QAaXJCKkpBoYDQra Qwu+Xp4vdH1xoMD/4gT/DmH1uaK+TQsvTt9c2Hnq3bru6pxt19t7OKeeMnp+4nH8rbN3F5n4 Sf2Z+aN4ltsGzekPS4KrtY5UzMhhlZgYz7BCb6KQk2W/jaAM28xvE4VsuaVf+X4KErsnXblw 9YEvb//EPu67KW9sKH2LZYFzWXL05Ug9JZbijERDLeai4kQAvsUqfScDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/pQRiMz0NjwcAG9Jazm8Aex40UX8>
Subject: [OAUTH-WG] Token Chaining Use Case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 26 Mar 2015 18:31:30 -0000

As requested after last night’s informal meeting, here is the token chaining use case that I want to see represented in the token swap draft.


[ Client ]  ->   [ A ] -> [ B ] -> [ C ]

An OAuth client gets an access token AT1, just like it always would, with scopes [A, B, C] in order to call service A, which requires all three scopes. Service A (an RS) accepts this token since it has its scope, and then needs to call service B in turn, which requires scopes [B, C]. It could just re-send the token it got in, AT1, but that would give the downstream RS the ability to call services with scope [ A ] and it should not be allowed to do that. To limit exposure, service A calls a token swap at the AS to create AT2 with scopes [ B, C ], effectively acting as an OAuth client requesting a downscoped token based on AT1. Service A then acts as an OAuth client to call service B, now acting as an RS to service A’s client, and can fulfill the request. And it’s turtles all the way down: Service B can also call service C, and now B acts as a client, requesting AT3 with scope [ C ] based on AT2, and sending AT3 to service C. This prevents C from being able to call B or A, both of which would have been available if AT1 had been passed around. Note that service A or the Client can also request a downscoped token with [ C ] to call service C directly as well, and C doesn’t have to care how it got there.


In other words, it lets the client software be very, very dumb. It doesn’t have to do any special processing, doesn’t have to know what’s in the token, it just follows the recipe of “I got a token, I get another token based on this to call someone else”. It’s also analogous to the refresh token flow, but with access tokens going in and out. I’ve deployed this setup several times in different service deployments. Even though there is a performance hit in the additional round trips (as Phil brought up in another thread), in these cases the desire to have the tokens hold least privilege access rights (smallest set of scopes per service) outweighed any performance hit (which was shown to be rather small in practice).

What I want is for the token swap draft to define or use a mechanism that allows us to do this. I think we can do that pretty easily by adjusting the token swap syntax and language, and explicitly calling out the semantic processing portion (the current core of the document) for what it is: a way for a token issuer to communicate to a token service specific actions. At a high level, the spec would be something like:



1. How to swap a token at an AS
  1. Send a request to the token endpoint with a new grant type, and a token (of any type/format/flavor) on the way in
  2. Get back a new token in a token response
2. Communicating act as / on behalf of semantics via a JWT assertion
  1. How to create (as an AS/RS/client/other issuer) a JWT with act-as semantics
  2. What to do (as an AS/RS) with a JWT with act-as semantics
  3. How to create a JWT with on-behalf-of semeantics
  4. What to do with a JWT with on-behalf-of-semantics
  5. How to possibly represent these semantics with something other than a JWT



Section 2 uses the syntax from section 1. Other applications, like the one I laid out above, can use the syntax from section 1 as well. This works for structured, unstructured, self-generated, cross-domain, within-domain, and other tokens.


 — Justin