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.)
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:jric...@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.jo...@microsoft.com
<mailto:michael.jo...@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-boun...@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 <jric...@mit.edu
<mailto:jric...@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
