[OAUTH-WG] OAuth Service Chaining
Justin Richer <jricher@mitre.org> Fri, 07 September 2012 14:28 UTC
Return-Path: <jricher@mitre.org>
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 96A4E21E80B1 for <oauth@ietfa.amsl.com>; Fri, 7 Sep 2012 07:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.523
X-Spam-Level:
X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OljTUWNmg1FR for <oauth@ietfa.amsl.com>; Fri, 7 Sep 2012 07:28:54 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 945B621E8099 for <oauth@ietf.org>; Fri, 7 Sep 2012 07:28:54 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0986E21B19C7 for <oauth@ietf.org>; Fri, 7 Sep 2012 10:28:54 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E5F1721B19BA for <oauth@ietf.org>; Fri, 7 Sep 2012 10:28:53 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.1; Fri, 7 Sep 2012 10:28:53 -0400
Message-ID: <504A04A1.1030905@mitre.org>
Date: Fri, 07 Sep 2012 10:28:49 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
References: <20120907141353.23675.56298.idtracker@ietfa.amsl.com>
In-Reply-To: <20120907141353.23675.56298.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20120907141353.23675.56298.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------070004040208030303030200"
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] OAuth Service Chaining
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 07 Sep 2012 14:28:55 -0000
In many of the systems that I've run into, especially legacy systems, we have multiple independent services that need to work in concert with each other to fulfill a service request. In a SAML based world, somebody usually builds up an uber-assertion that gets passed around to all the services, who each check it to make sure it's got the bits in it that they care about. I've been asked by several people how we can solve this in an OAuth world, and we can of course do this same exact thing with OAuth bearer tokens, using either introspection or structured tokens to fulfill the SAML-parsing role. But I think that tokens are fundamentally different from assertions, and that we can do better. What if, instead, a client gets a token from an AS, like usual, and passes it to the RS, like usual. But then that RS could in turn talk to the RS to get another token so that it can call a second RS. This secondary token can have at most the same rights as the original token. For all intents and purposes, this is the refresh tokens flow, but with one major difference: it's the RS that's trading one AT for another AT. This is important, since the RS won't ever have the refresh token (and shouldn't!). With that flow in mind, I've submitted a rough outline for a new grant type and method of using OAuth2 bearer tokens in a chained environment, to facilitate discussion in this group about it. It's a pattern we plan on implementing here, so whether it eventually becomes a WG item or an individual submission, I thought it would be useful to get it out in the open. It doesn't yet have the normative cross-references or the formal IANA registration language in it, but the core of the flow is there. http://tools.ietf.org/html/draft-richer-oauth-chain-00 I look forward to comments and discussion. -- Justin -------- Original Message -------- Subject: New Version Notification for draft-richer-oauth-chain-00.txt Date: Fri, 7 Sep 2012 07:13:53 -0700 From: <internet-drafts@ietf.org> To: <jricher@mitre.org> A new version of I-D, draft-richer-oauth-chain-00.txt has been successfully submitted by Justin Richer and posted to the IETF repository. Filename: draft-richer-oauth-chain Revision: 00 Title: A Method of Bearer Token Redelegation and Chaining for OAuth 2 Creation date: 2012-09-07 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-richer-oauth-chain-00.txt Status: http://datatracker.ietf.org/doc/draft-richer-oauth-chain Htmlized: http://tools.ietf.org/html/draft-richer-oauth-chain-00 Abstract: This document provides a method for a resource server to present a token that it has received from a client back to its authorization server for the purposes of receiving a derivative token for use on another resource server in order to chain together service requests. The IETF Secretariat
- Re: [OAUTH-WG] OAuth Service Chaining William Mills
- [OAUTH-WG] OAuth Service Chaining Justin Richer
- Re: [OAUTH-WG] OAuth Service Chaining William Mills
- Re: [OAUTH-WG] OAuth Service Chaining Justin Richer
- Re: [OAUTH-WG] OAuth Service Chaining Justin Richer