AS already has the problem of checking requested scopes, this doesn't change
that.
In fact an AS could issue a new "refresh token" in return for the presented one
(which is the user/app AT) that's limited to be used by the RS as a client.
If one of the things we want is the ability to have the AS return N access
tokens, one for each scope allowing the RS to make a single round trip request
to the AS for all of the more limited scope tokens, then a new grant type is in
fact needed.
On Thursday, March 26, 2015 3:33 PM, Donald F. Coffin
<[email protected]> wrote:
#yiv7149031579 #yiv7149031579 -- _filtered #yiv7149031579
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv7149031579
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv7149031579
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv7149031579
{font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv7149031579
{panose-1:3 6 8 2 4 4 6 7 3 4;}#yiv7149031579 #yiv7149031579
p.yiv7149031579MsoNormal, #yiv7149031579 li.yiv7149031579MsoNormal,
#yiv7149031579 div.yiv7149031579MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579 a:link,
#yiv7149031579 span.yiv7149031579MsoHyperlink
{color:blue;text-decoration:underline;}#yiv7149031579 a:visited, #yiv7149031579
span.yiv7149031579MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv7149031579
p.yiv7149031579msonormal, #yiv7149031579 li.yiv7149031579msonormal,
#yiv7149031579 div.yiv7149031579msonormal
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579
p.yiv7149031579msolistparagraph, #yiv7149031579
li.yiv7149031579msolistparagraph, #yiv7149031579
div.yiv7149031579msolistparagraph
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579
p.yiv7149031579msochpdefault, #yiv7149031579 li.yiv7149031579msochpdefault,
#yiv7149031579 div.yiv7149031579msochpdefault
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579
p.yiv7149031579msonormal1, #yiv7149031579 li.yiv7149031579msonormal1,
#yiv7149031579 div.yiv7149031579msonormal1
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579
p.yiv7149031579msochpdefault1, #yiv7149031579 li.yiv7149031579msochpdefault1,
#yiv7149031579 div.yiv7149031579msochpdefault1
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579
span.yiv7149031579msohyperlink {}#yiv7149031579
span.yiv7149031579msohyperlinkfollowed {}#yiv7149031579
span.yiv7149031579msohyperlink1 {}#yiv7149031579
span.yiv7149031579msohyperlinkfollowed1 {}#yiv7149031579
span.yiv7149031579emailstyle171 {}#yiv7149031579 span.yiv7149031579emailstyle27
{}#yiv7149031579 p.yiv7149031579msonormal2, #yiv7149031579
li.yiv7149031579msonormal2, #yiv7149031579 div.yiv7149031579msonormal2
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579
span.yiv7149031579msohyperlink2
{color:blue;text-decoration:underline;}#yiv7149031579
span.yiv7149031579msohyperlinkfollowed2
{color:purple;text-decoration:underline;}#yiv7149031579
p.yiv7149031579msolistparagraph1, #yiv7149031579
li.yiv7149031579msolistparagraph1, #yiv7149031579
div.yiv7149031579msolistparagraph1
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579
p.yiv7149031579msochpdefault2, #yiv7149031579 li.yiv7149031579msochpdefault2,
#yiv7149031579 div.yiv7149031579msochpdefault2
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579
p.yiv7149031579msonormal11, #yiv7149031579 li.yiv7149031579msonormal11,
#yiv7149031579 div.yiv7149031579msonormal11
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579
span.yiv7149031579msohyperlink11
{color:blue;text-decoration:underline;}#yiv7149031579
span.yiv7149031579msohyperlinkfollowed11
{color:purple;text-decoration:underline;}#yiv7149031579
span.yiv7149031579emailstyle1711
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none
none;}#yiv7149031579 p.yiv7149031579msochpdefault11, #yiv7149031579
li.yiv7149031579msochpdefault11, #yiv7149031579
div.yiv7149031579msochpdefault11
{margin-right:0in;margin-left:0in;font-size:10.0pt;}#yiv7149031579
span.yiv7149031579emailstyle271
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none
none;}#yiv7149031579 span.yiv7149031579EmailStyle39
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none
none;}#yiv7149031579 .yiv7149031579MsoChpDefault {font-size:10.0pt;} _filtered
#yiv7149031579 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv7149031579
div.yiv7149031579WordSection1 {}#yiv7149031579 Bill, Thanks for the
clarification. How do you propose the AS deal with the following RFC6749
Section 6. Refreshing an Access Token requirement? ScopeOPTIONAL. The scope
of the access request as described by Section 3.3. The requested scope MUST
NOT include any scope not originally granted by the resource owner, and if
omitted is treated as equal to the scope originally granted by the resource
owner. The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the new
refresh token. The authorization server MAY revoke the old refresh token after
issuing a new refresh token to the client. If a new refresh token is issued,
the refresh scope MUST be identical to that of the refresh token included by
the client in the request. Since the RS is attempting to obtain a new AT, what
happens to the old AT that was submitted as a refresh_token, should the AS
issue a new refresh_token, which it is allowed to do as stated above? Since
this was really an AT, doesn’t this mean the RS and issuing AS will be required
to REVOKE the AT? If the AS is not the AS that issued the original AT and
there is no scope= value in the request, how does it ensure the request isn’t
asking for more access than was granted by the granting AS? Best
regards,DonDonald F. CoffinFounder/CTO REMI Networks2335 Dunwoody Crossing
Suite EDunwoody, GA 30338-8221 Phone: (949) 636-8571Email:
[email protected] From: Bill Mills
[mailto:[email protected]]
Sent: Thursday, March 26, 2015 6:04 PM
To: Bill Mills; Donald F. Coffin; 'Phil Hunt'
Cc: [email protected]
Subject: Re: [OAUTH-WG] Token Chaining Use Case Again, I don't think
requiring a call out to an internal token reissuer is a general solution. That
said... The RS calls the token endpoint treating the AT as a refresh token in
all cases and using the refresh_token grant type. Desired scope is specified
by the RS. It's not in spec if there are derivative internal scopes not in the
original scope list though. This doesn't support internal scopes for
partitioning that the AS doesn't know about. An internal AS providing chaining
would need to understand the AT just as the RS does, and treat it as a refresh
token. -bill On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin
<[email protected]> wrote: Bill, Can you clarify your thoughts on
the following: · What AS endpoint does the RS call and how does it
present the AT he received?· What is the grant_type value the RS use in
the above endpoint request?· What does the AS do if the AT was issued
by another AS (which is possible using Justin’s use case)? Best
regards,DonDonald F. CoffinFounder/CTO REMI Networks2335 Dunwoody Crossing
Suite EDunwoody, GA 30338-8221 Phone: (949) 636-8571Email:
[email protected] From: Bill Mills [mailto:[email protected]]
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: [email protected]
Subject: Re: [OAUTH-WG] Token Chaining Use Case The RS calling back to the AS
won't be confused, the token it gets would be it's refresh token. I don't see
any reason why the AS can't be smart enough to know that a token that looks
like an access token it issued is usable as a refresh token for limited
purposes or downscoping. On Thursday, March 26, 2015 1:46 PM, Donald F.
Coffin <[email protected]> wrote: -1 Although Justin’s point
might be a bit pre-mature as far as a standards discussion, the more critical
reason IMHO is calling the AS’s /Token endpoint with a grant_type of
“refresh_token” but providing an issued AT rather than an issued refresh_token
(RT) will definitely create a backwards compatibility issue for many
implementations. Best regards,DonDonald F. CoffinFounder/CTO REMI Networks2335
Dunwoody Crossing Suite EDunwoody, GA 30338-8221 Phone: (949)
636-8571Email: [email protected] From: Phil Hunt
[mailto:[email protected]]
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc: <[email protected]>
Subject: Re: [OAUTH-WG] Token Chaining Use Case +1. We all have to change
production code when non final specs evolve. I particularly don't see this as
a valid argument at the start of a standards discussion.
Phil
On Mar 26, 2015, at 15:13, Bill Mills <[email protected]> wrote:
By definition an access token is becoming a form of refresh token. The
"because my implementation didn't do it that way" isn't convincing me. On
Thursday, March 26, 2015 12:44 PM, Justin Richer <[email protected]> wrote:
Because many implementations (including mine which does support my old token
chaining draft) treat access tokens and refresh tokens separately in terms of
data store and structure. Additionally, the refresh token is tied to the client
and presented by the client. But in this case it's someone downstream, an RS,
presenting the token. So unlike a refresh token being presented by the one it
was issued to, this token is being presented by someone it was presented to.
The feeling is close, but not quite the same in either development or
assumptions. -- Justin / Sent from my phone /
-------- Original message --------
From: Bill Mills <[email protected]>
Date: 03/26/2015 2:24 PM (GMT-06:00)
To: Justin Richer <[email protected]>, "<[email protected]>" <[email protected]>
Subject: Re: [OAUTH-WG] Token Chaining Use Case So why can't the access tokne
simply be re-used as a refresh token? Why would it need a new grant type at
all? On Thursday, March 26, 2015 11:31 AM, Justin Richer <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
