Re: [OAUTH-WG] Token Chaining Use Case

Sergey Beryozkin <sberyozkin@gmail.com> Wed, 08 July 2015 09:26 UTC

Return-Path: <sberyozkin@gmail.com>
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 B6DA01B29DA for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2015 02:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 EQQVX8OK29F7 for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2015 02:26:29 -0700 (PDT)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (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 50B7D1B2C4E for <oauth@ietf.org>; Wed, 8 Jul 2015 02:26:29 -0700 (PDT)
Received: by wgck11 with SMTP id k11so190321921wgc.0 for <oauth@ietf.org>; Wed, 08 Jul 2015 02:26:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LZbZrsZxAxCEkfpqVCQV4nBkzGoWBW2zMjcUSdQKwdg=; b=sWQLGzyKt284MXHbVv1e0RB5GhIL/iULa32OYD7zYBpOI9I1MFc2TMmId+9MMEviIC n4Kz9j/GtyaRNKDsseT2R5RfexzDfHk065RnC6op+biwBix1pktMMGzOdp6pgovXzydr b/LdzjEaguKc7M02/HHTgrarXpv3TuyDtpOwmenrcF36tbozIpReXVEn3TDQr779uNVe 0C6BXZDnGyGlvl//u0xhoBgWX9O1I4e4i51ALeuWCjzBtqgtGO5ub/j5FYci+7G05puO QQkob/IKR6uKVa6vv2Z0C/HycJsIfdK3vjYJ0fj3z8TR2zW9/RFjLAh104B5PCXn4vRa itdQ==
X-Received: by 10.194.89.72 with SMTP id bm8mr17916806wjb.116.1436347588002; Wed, 08 Jul 2015 02:26:28 -0700 (PDT)
Received: from [10.36.226.2] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id s11sm1869773wib.19.2015.07.08.02.26.26 for <oauth@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 02:26:27 -0700 (PDT)
Message-ID: <559CECB5.4000006@gmail.com>
Date: Wed, 08 Jul 2015 10:26:13 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <D0E09E09-A803-427A-ACA9-D9E3F3EF31E5@mit.edu> <CA+k3eCSgE0Df25kPiKVnyWkkvONke6ha_FrVmZiOYYTVGM6w_w@mail.gmail.com> <BY2PR03MB442F6D96703377B6673509AF5920@BY2PR03MB442.namprd03.prod.outlook.com> <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> <BY2PR03MB442AF9C598B811217B1161DF5910@BY2PR03MB442.namprd03.prod.outlook.com>
In-Reply-To: <BY2PR03MB442AF9C598B811217B1161DF5910@BY2PR03MB442.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/7qDRcP-P6KfqLBlKHiCap0PV0Qw>
Subject: Re: [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: <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, 08 Jul 2015 09:26:33 -0000

Hi,
On 08/07/15 01:41, Mike Jones wrote:
> I’ll start by saying that if you compare
> https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02,
> unsurprisingly, you’ll find a lot in common.  Both have requests and
> responses formatted using JSON objects, both have input and output
> tokens, both have security token type parameters describing their
> corresponding inputs and outputs.  Both can convey act_as and
> on_behalf_of tokens.  And despite what was written below, both define a
> new grant_type value that is used to make this new kind of request at
> the Token Endpoint.
>
> The primary thing that Brian’s draft is missing semantically is the
> ability for the requester to sign the set of input parameters.  This is
> critical to establishing proper trust to enable the exchange to occur in
> many use cases.  That’s why the WG draft uses a JWT as the request – so
> a signature can be applied to the request, when appropriate.  (And when
> it’s not needed, “alg”: “none” can be used.)
>

The requester is a client talking to the token endpoint and this client 
needs to authenticate, why it needs to sign the token-exchange related 
parts too ?

Thanks, Sergey

> Justin, you’re right that the current WG draft doesn’t have a separate
> “input token” request parameter.  In the current draft, the (optionally)
> signed request **is** the input token.  Thinking some more about the
> token chaining use case you’re interested in, I see why you want to have
> that token to be a separate element in the request.  I believe the best
> way to accomplish that is to add an optional claim to the request that
> would contain that token.  (I think the closest equivalent in Brian’s
> draft is the possibility of using an access token or assertion as the
> client authentication mechanism, possibly passing it as defined in RFC
> 6750, although the draft doesn’t say that.)  Passing the input token as
> a claim lets it be part of the signed request.
>
> It’s completely up to us when using a different grant_type to define
> what the input and output parameters when using that grant_type are.
> (RFC 6749 already has different sets, depending upon the grant_type
> used.)  I personally find it cleaner to return the output security token
> that may not be an access token in a “security_token” parameter rather
> than repurposing the “access_token” parameter to hold something that’s
> not an access token, but now we’re more discussing syntax than
> semantics.  Still, if something is different, it’s probably less error
> prone to use a different syntax for it.
>
> I’m sympathetic to your comment about Nat’s signed requests draft,
> except that the requests that draft specifies are requests to the
> interactive Authorization Endpoint, whereas the requests we’re dealing
> with here are requests to the non-interactive Token Endpoint.  Still,
> thinking of the Token Exchange requests as signed requests to the Token
> Endpoint, just like Nat’s draft makes signed requests to the
> Authorization Endpoint, is probably a good unifying mental framework for
> all of us to consider applying to this problem space.
>
>                                                                  Best
> wishes,
>
>                                                                  -- Mike
>
> *From:*Justin Richer [mailto:jricher@mit.edu]
> *Sent:* Tuesday, July 07, 2015 4:47 PM
> *To:* Mike Jones
> *Cc:* Brian Campbell; <oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case
>
> This approach is not a good fit for my use cases, and it’s still not
>   OAuth-y at all. It requires a specially-formed security assertion on
> the way in, which the client must understand and generate. I still can’t
> take an arbitrary token I’ve been handed by someone else and pass it off
> to be pushed forward. The new “*_type” parameters seem to merely kick
> the can down the road instead of addressing the problems with the
> current specification.
>
> I think that Brian’s approach works much better. It unrolls important
> parameters, properly uses the token endpoint, and allows for arbitrarily
> formatted input tokens.
>
> When combined with Nat’s draft that specifies how to perform all generic
> OAuth requests as JWTs (or even some of the upcoming PoP work if we ever
> do that), you’ve pretty much got the draft below but with much more
> flexibility and power.
>
>   — Justin
>
>     On Jul 7, 2015, at 6:51 PM, Mike Jones <Michael.Jones@microsoft.com
>     <mailto:Michael.Jones@microsoft.com>> wrote:
>
>     As just updated <http://self-issued.info/?p=1412>, I believe that
>     the working group token exchange draft
>     https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can
>     now also serve the “OAuthy” token exchange use cases, such as Justin
>     and Phil’s token chaining use case, as well as support general token
>     exchange, including exchange of JWT and SAML tokens.  The mechanism
>     would be the same one that Brian suggested below – defining security
>     token type values for OAuth 2.0 access tokens and refresh tokens –
>     enabling them to be used as inputs and outputs in any of the token
>     exchanges.
>
>     For instance, by using “access token” as the input security token
>     type, providing new scope values, and using “access token” as the
>     output security token type, token chaining is achieved.
>
>     Now, a question for the working group…  What should the security
>     token type values for access token and refresh token be?  Two
>     different choices seem to make sense.
>
>     (1)  Use the values “access_token” and “refresh_token”, which are
>     used in RFC 6749 token response values.
>
>     (2)  Define new URNs for this usage, such as
>     urn:ietf:params:oauth:token-type:access-tokenand
>     urn:ietf:params:oauth:token-type:refresh-token.
>
>     I’d personally be fine just using the short names in (1).
>
>     If people agree with this approach, we can document this usage in
>     the -03 draft and publish it as soon as the submission tool reopens
>     Monday morning during IETF 93.
>
>                                                                      -- Mike
>
>     *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
>     Campbell
>     *Sent:* Thursday, March 26, 2015 3:15 PM
>     *To:* Justin Richer
>     *Cc:* <oauth@ietf.org <mailto:oauth@ietf.org>>
>     *Subject:* Re: [OAUTH-WG] Token Chaining Use Case
>
>     This kind of token exchange might involve exchanges other than
>     swapping an AT for another AT (and downscoping it). It might be an
>     AT for a structured JWT specifically targeted at one of the the
>     particular services that the original RS needs to call. Or an AT
>     might be exchanged for a SAML assertion to use with legacy SOAP
>     serveries.  A good general token exchange mechanism enables lots of
>     variations of cases like the one Justin mentioned. And more. In
>     fact, I think downscoping might be a minority use case where what
>     token exchange is often need for is translating tokens from what you
>     have into what the resource you need to call can deal with.
>
>     There need to be ways for the caller to tell the AS about the token
>     it's asking for - by type or by the address/identifier of where
>     it'll be used. There needs to be ways for the caller to authenticate
>     to the AS. And there needs to be some way of expressing this
>     delegation thing (though I'm still not totally convinced it couldn't
>     be just the token is about the user/principal and the caller/client
>     of the exchange is who is being delegated to).
>
>     I realize few (approaching zero) people have or are going to read it
>     but I have endeavored to cover all these things in the
>     http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's
>     an early draft so not without it some rough edges but can provide
>     some guidance on what is needed and offers some protocol syntax for
>     expressing it. I believe Justin's use case would be covered by it
>     (defining a specific token type URI for an OAuth access token issued
>     by the AS in question might be needed) as are many others.
>
>     On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer <jricher@mit.edu
>     <mailto:jricher@mit.edu>> wrote:
>
>     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
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com