You're doubling the number of back end calls to satisfy a request though, and
in the end you're only really getting a benefit when the back end system would
never see an ubertoken anyway.
________________________________
From: Justin Richer <[email protected]>
To: William Mills <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Friday, September 7, 2012 8:08 AM
Subject: Re: [OAUTH-WG] OAuth Service Chaining
On 09/07/2012 10:51 AM, William Mills wrote:
Are you trying to limit how widely the more powerful token gets used so peer
systems can't access each other? What problem does this solve?
>
Exactly -- it keeps you from passing around the ubertoken to all of
your systems, especially when they don't need it. It lets you better
scope what each system is doing. Additionally, it gets you away from
passing on the access token that you were passed in, which I see as
an anti-pattern that's potentially almost as dangerous as passing
along a user's primary credential, the original problem that OAuth
sought to solve.
That said I think you want to turn in an AT and get back N tokens with all
possible subordinate scopes if in fact this is worth doing. AT1 with scop "a
b" could be split to "a" and "b", or it could return "a_1", "a_2", and "b"
tokens. The AS will know the mapping policy.
But then you'd also have to define a multi-access-token response
format, and I think that's better left to its own pluggable
mechanism. Such a mechanism could be used here because there's
nothing in here that says what's returned has to be another single
bearer token. (Though if you do that, it lets you go turtles all the
way down at the next RS.)
-- Justin
>
>
>________________________________
> From: Justin Richer <[email protected]>
>To: "[email protected]" <[email protected]>
>Sent: Friday, September 7, 2012 7:28 AM
>Subject: [OAUTH-WG] OAuth Service Chaining
>
>
>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: <[email protected]>
>To: <[email protected]>
>
>
>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
>
>
>
>_______________________________________________
>OAuth mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
