Subject: [OAUTH-WG] Using structured access_token as grant type in assertion flow

From: Lewis Adam-CAL022 <[email-masked]>
Date: Mon, 10 Dec 2012 14:34:14 +0000

Hi,

I continue to have an interest in the OAuth assertion profiles for my use cases.  I'm wondering if the idea of performing a first OAuth dance which returns to the client a structured JWT access token (with scope=AS for example) could then be used as the JWT in an assertion grant type?  So something like this (I show the RO credential flow since it is the simplest to draw, but same idea for the code flow):

Client		AS
|			|
|---------------->| (authorization request scope=AS, grant_type=RO password credentials)
|			|
|<----------------| (token response with access_token scoped to AS)
|			|
|---------------->| (authorization request, scope=xyz, grant_type=JWT assertion as obtained from previous step)
|			|
|<----------------| (token response with access token scoped to xyz)

I suppose there is nothing in theory which should prevent this, but I am wondering if anybody else has thought of such a usage.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 14 Dec 2012 14:14:28 -0700

Maybe I'm missing the bigger picture but, if your going back to the same AS
like the diagram shows, why not just request the xyz scope in the initial
request and cut out the middle steps?

More generally I can say I've thought about these kinds of token exchange
cases and they should be possible in theory. In practice I expect getting
everything to work and validate correctly with respect to scopes and
audience values might be a little tricky.

On Mon, Dec 10, 2012 at 7:34 AM, Lewis Adam-CAL022 <
[email-masked]> wrote:

> Hi,
>
> I continue to have an interest in the OAuth assertion profiles for my use
> cases.  I'm wondering if the idea of performing a first OAuth dance which
> returns to the client a structured JWT access token (with scope=AS for
> example) could then be used as the JWT in an assertion grant type?  So
> something like this (I show the RO credential flow since it is the simplest
> to draw, but same idea for the code flow):
>
>
> Client          AS
> |                       |
> |---------------->| (authorization request, scope=xyz, grant_type=JWT
> assertion as obtained from previous step)
> |                       |
> I suppose there is nothing in theory which should prevent this, but I am
> wondering if anybody else has thought of such a usage.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 15 Dec 2012 10:40:03 +0900

If I understand correctly, there are multiple devices with clients with the
same client_id involved and you want to revoke individual devices when
needed. You also do not want to store the password.

In a sense, the JWT is working like a device specific password with
distributed verifier. This is a valid and potentially a common pattern.

=nat via iPhone

Dec 15, 2012 6:15、Brian Campbell <[email-masked]> のメッセージ:

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Mon, 17 Dec 2012 15:39:32 +0000

Hi Brian,

Right ... so I suppose looking at that diagram without the background text would have been a bit odd :)

In my use case I have an OAuth client that is going to request many access tokens, for many different resource servers.  All of these resources servers will be protected by the same AS.

(I think this is similar to Google's OAuth in that they have many APIs served by many resource servers, which all use the same OAuth authorization endpoint).

My client *could* ask for an access token with enough scopes to cover all the resource server APIs (again, similar for example to the Google OAuth playground), but this does not meet the assurance levels of my use cases.  RS1 has no business possessing an AT that could be used to access protected resources at AS2 and AS2 has no business having the same AT that would allow it access protected resource at AS3, and so on.

I have toyed around with the idea making an initial OAuth request with an uber-scope, and then using the refresh token to obtain the down-scoped access tokens and sending those down-scoped access tokens to the RS's.  But the problem I'm running into with this is that my client may not know a priori all the RS's it's going to need access tokens for.

So the JWT assertion flow began to look nearly perfect to me.  If you look at the diagram again, it should look (very) familiar to something we all grew up with: Kerberos!  The first exchange is to obtain the TGT, and the subsequent exchange uses the TGT to get a service ticket.  So using this analogy:

Kerberos TGT = JWT assertion
Kerberos TGS = access token

I can use the JWT assertion obtained in step 1 to request access tokens on the fly for resource servers at the client needs to access them, just as the TGT is used to obtain the TGS on-demand.

I think this is totally within the realm of reason.  We will likely prototype this idea very early next year (Jan/Feb).

-adam

From: Brian Campbell [mailto:[email-masked]]
Sent: Friday, December 14, 2012 3:14 PM
To: Lewis Adam-CAL022
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Using structured access_token as grant type in assertion flow

Maybe I'm missing the bigger picture but, if your going back to the same AS like the diagram shows, why not just request the xyz scope in the initial request and cut out the middle steps?

More generally I can say I've thought about these kinds of token exchange cases and they should be possible in theory. In practice I expect getting everything to work and validate correctly with respect to scopes and audience values might be a little tricky.

On Mon, Dec 10, 2012 at 7:34 AM, Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Client          AS
|                       |

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth