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?
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.
________________________________
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
