Subject: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 Jan 2011 15:17:47 -0700

I'm having some doubts about the code_and_token response type.

The reason why we have both token and code response type is that each has specific security characteristics. However, the mix raises questions about token scope and other properties.

For example, -11 states that the scope in the token request can only be equal or less than the scope requested in the authorization request. This means the token issued in the redirection (which is considered less trusted due to lack of client authentication) can have a greater scope than that issued using the code, but not the other way around which actually makes more sense.

If there is no difference in the properties of the two tokens issued (one directly in the redirection and another via the code), why do we need this complexity? Why can't the client just pass along the same token to the server? If there is a difference, it can only be that the token obtained using the code is "more powerful".

Adding two scope parameter to the authorization request seems complex, but so other ideas on asking for one authorization with two different tokens issued as a result.

Any thoughts?

It would be most useful if someone who deployed this (or is planning to) can explain how they are using it. Mostly if they are issuing tokens with the same or different security properties.

In -12, I am moving back to the -05 specification structure of profiles (flows). This means this code_and_token hybrid needs to be explained beyond just the definition of the extra parameter and response format. But I don't know how to describe such a profile or what the security considerations for such a hybrid look like.

If we can't nail this down quickly, I propose we move this out of the specification and let someone who has implementation experience define it as an extension.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Mon, 10 Jan 2011 14:30:35 -0800

On Mon, Jan 10, 2011 at 2:17 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> In -12, I am moving back to the -05 specification structure of profiles
> (flows).

Sweet!

> This means this code_and_token hybrid needs to be explained beyond
> just the definition of the extra parameter and response format. But I don’t
> know how to describe such a profile or what the security considerations for
> such a hybrid look like.

Does this help?

http://www.ietf.org/mail-archive/web/oauth/current/msg03655.html

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 Jan 2011 15:39:03 -0700

> -----Original Message-----
> From: Brian Eaton [mailto:[email-masked]]
> Sent: Monday, January 10, 2011 2:31 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Proposal to drop/relocate
> response_type=code_and_token
> 
> > In -12, I am moving back to the -05 specification structure of
> > profiles (flows).
> 
> Sweet!
> 
> > just the definition of the extra parameter and response format. But I
> > don't know how to describe such a profile or what the security
> > considerations for such a hybrid look like.
> 
> Does this help?
> 

This explains why you want the code returned in the fragment, but not why you need both code and token in the same response, as well as any differences in the token attributes,

EHL

---

From: Brian Eaton <[email-masked]>
Date: Mon, 10 Jan 2011 14:53:00 -0800

> This explains why you want the code returned in the fragment, but not why you need both code and token in the same response, as well as any differences in the token attributes,

The token in the same response is a latency optimization.  It is used
to start rendering iframes and script with interesting content while
the code is still being processed.

The code is used as a short-lived token that can be swapped for a
long-lived (refresh token).

I would expect the attributes of the refresh token and access tokens
to be equivalent.  The primary difference is credential lifetime.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 Jan 2011 16:06:34 -0700

> Sent: Monday, January 10, 2011 2:53 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > This explains why you want the code returned in the fragment, but not
> > why you need both code and token in the same response, as well as any
> > differences in the token attributes,
> 
> The token in the same response is a latency optimization.  It is used to start
> rendering iframes and script with interesting content while the code is still
> being processed.
> 
> The code is used as a short-lived token that can be swapped for a long-lived
> (refresh token).
> 
> I would expect the attributes of the refresh token and access tokens to be
> equivalent.  The primary difference is credential lifetime.

What about the difference between the two access tokens? The one issued directly and the one via the code? Are those the same? Same scope? Same duration?

I think this needs to be presented as a separate profile from the user-agent one because it will make it easier to better describe the security consideration of each. Can you offer a 1-2 paragraphs introduction of this profile, maybe as reference to the user-agent and server profiles?

EHL

---

From: Phil Hunt <[email-masked]>
Date: Mon, 10 Jan 2011 15:22:47 -0800

What about the idea that the code is only used as a hand-off mechanism between service components (e.g. authorization manager vs, resource access manager).  In that case, the code would not be usable for anything except to get an access token (which still requires client auth).  A code might have a very short expiration period with a limited number of uses (e.g. ONE). 

The frames timing issue is interesting, but doesn't it suggest a profile where the whole code step is bypassed (e.g. by receiving code and token)?

In general I perceive a code as being relatively simple (e.g. like an artifact), short lived, and having almost no rights (except to obtain a an access/refresh token).

Phil
[email-masked]

On 2011-01-10, at 3:06 PM, Eran Hammer-Lahav wrote:

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

---

From: Brian Eaton <[email-masked]>
Date: Mon, 10 Jan 2011 15:25:16 -0800

> What about the difference between the two access tokens? The one issued directly and the one via the code? Are those the same? Same scope? Same duration?

Same.

> I think this needs to be presented as a separate profile from the user-agent one because it will make it easier to better describe the security consideration of each.

That seems wrong, AFAICT everyone interested in implementing the
user-agent profile supported the mode where a verification code is
returned.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 10 Jan 2011 15:30:19 -0800

> user-agent profile supported the mode where a verification code is

As I recall, the verification code originally was a one-time use code that was short and could potentially be typed in the user, or could be passed to the rich client via the page title or other, related "hacks".

---

From: Brian Eaton <[email-masked]>
Date: Mon, 10 Jan 2011 15:31:07 -0800

> What about the idea that the code is only used as a hand-off mechanism between service components (e.g. authorization manager vs, resource access manager).  In that case, the code would not be usab…

I believe that is the case already for all of the uses of the
verification code in the spec.  IIRC, we settled on something where
the authorization code MUST have a short-lifetime, and SHOULD be
single-use.  Exchanging the authorization code for the refresh token
MUST require client auth.

The user-agent profile usage of the authorization code should not be
any different than the rest of the spec.

> The frames timing issue is interesting, but doesn't it suggest a profile where the whole code step is bypassed (e.g. by receiving code and token)?

The user-agent profile callback URL should end up looking like this:

/callback#code=<code>&token=<token>

The token component is there so immediately return a usable access
token to the relying party/client server.

The code component is there so the server-side components of the RP
can obtain a refresh token and additional access tokens.

> In general I perceive a code as being relatively simple (e.g. like an artifact), short lived, and having almost no rights (except to obtain a an access/refresh token).

It is very, very similar to the SAML artifact.  I think the only major
difference is that the SAML specs require a pre-configured return-to
URL for artifacts.  The OAuth2 spec allows for more dynamic return-to
URL settings by having the RP server present the actual callback URL
when it presents the artifact, and having the IdP check that the
callback URL matches the artifact.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 Jan 2011 16:42:53 -0700

> Sent: Monday, January 10, 2011 3:25 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > What about the difference between the two access tokens? The one
> issued directly and the one via the code? Are those the same? Same scope?
> Same duration?
> 
> Same.
> 
> > I think this needs to be presented as a separate profile from the user-agent
> one because it will make it easier to better describe the security
> consideration of each.
> 
> That seems wrong, AFAICT everyone interested in implementing the user-
> agent profile supported the mode where a verification code is returned.

Supported as in "+1" or running code?

These are two very different client profiles. In one, the client is completely authenticated, residing solely in the user-agent. The other is a mix authenticated and unauthenticated, where parts of the client can keep a secrets but others can't.

Being able to keep a secret is the primary differentiator when picking which profile to use. I agree that the hybrid one is an optimization of the web-server profile (removing the need to wait for the server to send a token back to the user-agent after exchanging the code). But that only means the code_and_token really belongs with the web-server profile than with the user-agent.

Moving to the profiles specification organization means that we need to present each distinct profile separately, and the code_and_token is clearly a distinct profile.

With your clarifications, I feel comfortable leaving it in, but not as a hack of either one of the other two profiles.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Tue, 11 Jan 2011 11:53:32 -0800

> Being able to keep a secret is the primary differentiator when picking which profile to use. I agree that the hybrid one is an optimization of the web-server profile (removing the need to wait for…

The two paragraphs above didn't make sense to me.

Once you have the hybrid flow, it meets all of the use cases that the
user-agent flow was trying to solve.  The hybrid flow is more
powerful, and has the same or better security characteristics.  So the
sensible thing to do is replace the user-agent flow, 100%, with the
hybrid flow.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 Jan 2011 13:45:01 -0700

The exact same argument can be made that the hybrid flow meets all the use cases of the web-server flow... which means we can keep the current single flow specification as is... :-)

What am I missing? (I'm asking).

EHL

> Sent: Tuesday, January 11, 2011 11:54 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > These are two very different client profiles. In one, the client is completely
> authenticated, residing solely in the user-agent. The other is a mix
> authenticated and unauthenticated, where parts of the client can keep a
> secrets but others can't.
> >
> > Being able to keep a secret is the primary differentiator when picking which
> profile to use. I agree that the hybrid one is an optimization of the web-
> server profile (removing the need to wait for the server to send a token back
> to the user-agent after exchanging the code). But that only means the
> code_and_token really belongs with the web-server profile than with the
> user-agent.
> 
> Once you have the hybrid flow, it meets all of the use cases that the user-
> agent flow was trying to solve.  The hybrid flow is more powerful, and has
> the same or better security characteristics.  So the sensible thing to do is
> replace the user-agent flow, 100%, with the hybrid flow.

---

From: Brian Eaton <[email-masked]>
Date: Tue, 11 Jan 2011 12:48:32 -0800

> What am I missing? (I'm asking).

The hybrid flow does not work well for applications that consist
mainly of server-side code.  The URL fragment is not transferred to
the web server, so they have to write extra client-side code to send
it up to their server.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 Jan 2011 14:21:57 -0700

But that's just an annoying implementation detail. If the only different now between the hybrid and web server flows is one character ('?' vs '#'), and all the other security considerations and rules (matching, registration, etc.) are the same, I don't see any point in going back to -05 structure. Otherwise, we have exactly the same section repeating twice or three times, with almost no differences (which actually makes it harder to pick).

EHL

> Sent: Tuesday, January 11, 2011 12:49 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > The exact same argument can be made that the hybrid flow meets all the
> > use cases of the web-server flow... which means we can keep the
> > current single flow specification as is... :-)
> >
> The hybrid flow does not work well for applications that consist mainly of
> server-side code.  The URL fragment is not transferred to the web server, so
> they have to write extra client-side code to send it up to their server.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 11 Jan 2011 23:33:42 +0100

the only difference I see is the code in the fragement will not show up 
in HTTP referers.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 11 Jan 2011 23:44:12 +0100

>The frames timing issue is interesting, but doesn't it suggest a 
profile where the whole code step is bypassed (e.g. by receiving code 
and token)?
> token to the relying party/client server.

Do you see any need to restrict the power of this token or is it as 
powerful as the tokens obtained using the code? I'm asking because this 
token is sent out without authenticating the client whereas exchange of 
code to tokens can be authenticated. A malicious client app could 
initiate the hybrid authorization process in a browser (embedded or 
external), pretend to be a legitimate client and obtain the token from 
the redirect_uri after the redirect.

regards,
Torsten.

---

From: Brian Eaton <[email-masked]>
Date: Tue, 11 Jan 2011 16:40:53 -0800

On Tue, Jan 11, 2011 at 1:21 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> But that's just an annoying implementation detail.

Yes.  The user-agent flow is a set of annoying implementation details
that are very, very useful if you want to make the protocol efficient.

> If the only different now between the hybrid and web server flows is one character ('?' vs '#'), and all the other security considerations and rules (matching, registration, etc.) are the same, I don't see any point in going back to -05 structure.
> Otherwise, we have exactly the same section repeating twice or three times, with almost no differences (which actually makes it harder to pick).

There is another important difference in the protocol flows.

The web-server flow only returns a verification code on the query.  It
does not return a token.  There are a couple of reasons for that.
- tokens returned on query strings have more ways to leak than tokens
returned in fragments.  A shorter-lived code is safer.
- the verification code requires client authentication to use.  This
makes it safer.  It also will, I think, get oauth2 based login
protocols up to LoA 2.

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Tue, 11 Jan 2011 16:43:28 -0800

On Tue, Jan 11, 2011 at 2:44 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> Do you see any need to restrict the power of this token or is it as powerful
> as the tokens obtained using the code? I'm asking because this token is sent
> out without authenticating the client whereas exchange of code to tokens can
> be authenticated. A malicious client app could initiate the hybrid
> authorization process in a browser (embedded or external), pretend to be a
> legitimate client and obtain the token from the redirect_uri after the
> redirect.

This is a good point, I think there are a set of people who won't
deploy the user-agent flow because it returns a token without seeing
the client secret.

They might choose to support the user-agent flow, but return less
privileged tokens.  I doubt we could standardize anything like that.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 12 Jan 2011 21:35:55 +0100

> privileged tokens.  I doubt we could standardize anything like that.

I would not want to standardize it either. My suggesstion would be to 
add a respective note to the security considerations. Based on that 
every deployment shall decide how to handle it.

regards,
Torsten.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 19 Jan 2011 17:50:31 -0800

> that are very, very useful if you want to make the protocol efficient.

Update: we're not planning on doing anything with code_and_token; we
think most use-cases can be met with one of three flows:

- query string, with a code
- fragment, with a token
- HTML 5 techniques, with either.  This is still a little new to
standardize, but we'll have our libraries use HTML 5 where possible.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 19:05:50 -0700

Can I take this as an endorsement for dropping it? It feels very experimental and should be easy to add as an extension.

As for your plan, will this work with a single authorization generating both a token and code?

EHL

> Sent: Wednesday, January 19, 2011 5:51 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> - HTML 5 techniques, with either.  This is still a little new to standardize, but
> we'll have our libraries use HTML 5 where possible.
> 
> Cheers,
> Brian

---

From: Brian Eaton <[email-masked]>
Date: Wed, 19 Jan 2011 18:09:43 -0800

> Can I take this as an endorsement for dropping it? It feels very experimental and should be easy to add as an extension.

I defer to the several other people who were interested in this
approach.  From memory, that's Brian Ellin, Luke Shephard, and Chuck
Mortimore.

> As for your plan, will this work with a single authorization generating both a token and code?

Sorry, I don't understand the question.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 19:11:10 -0700

> Sent: Wednesday, January 19, 2011 6:10 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > Can I take this as an endorsement for dropping it? It feels very
> experimental and should be easy to add as an extension.
> 
> I defer to the several other people who were interested in this approach.
> From memory, that's Brian Ellin, Luke Shephard, and Chuck Mortimore.
> 

Will this HTML5 magic involve making a single authorization request (redirection) or two?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 19:14:26 -0700

> From memory, that's Brian Ellin, Luke Shephard, and Chuck Mortimore.

Since no one else (other than you) showed any interest in keeping this section in for the past 9 days, I assume they don't care. I will remove this.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Wed, 19 Jan 2011 18:15:10 -0800

> Will this HTML5 magic involve making a single authorization request (redirection) or two?

It's not magic, it's window.postMessage().

It's an authenticated low-latency channel between windows or iframes.
There is more than one way to use it.  Not sure what we'll do exactly
yet.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 19 Jan 2011 18:20:51 -0800

> Since no one else (other than you) showed any interest in keeping this section in for the past 9 days, I assume they don't care. I will remove this.

This is an unfortunate assumption, and I think it could do serious
damage to the spec.  I think before you declare consensus to have
changed, it would be a good idea to reach out to the people who had
the original use cases to see what they think.

Very few people have the bandwidth to follow every thread on this
mailing list.  Furthermore, once they make sure that the spec is going
to address their needs they don't read the list as carefully.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 19:38:24 -0700

I am not going to spend the time it will take to write it in the new organization only to take it out later. I much rather take it out in -12 and put it right back in -13 if they rejoin us and show support.

As for damage, since this is a well-contained feature that is trivial to add as an extension, I don't see any problem.

It's ironic that you, who consistently wanted anything that is not back up by significant deployment experience removed, is pushing for including a feature that clearly belongs to that category. Even you are not going to use it.

EHL

> Sent: Wednesday, January 19, 2011 6:21 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > Since no one else (other than you) showed any interest in keeping this
> section in for the past 9 days, I assume they don't care. I will remove this.
> 
> This is an unfortunate assumption, and I think it could do serious damage to
> the spec.  I think before you declare consensus to have changed, it would be
> a good idea to reach out to the people who had the original use cases to see
> what they think.
> 
> Very few people have the bandwidth to follow every thread on this mailing
> list.  Furthermore, once they make sure that the spec is going to address
> their needs they don't read the list as carefully.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 20 Jan 2011 09:58:11 -0800

OK, looping in Chuck, Luke, and Brian.

Do you all remember the discussion we had a few months ago about
having the user-agent profile return a verification code in the
fragment?  The middle of the discussion thread is here:
http://www.ietf.org/mail-archive/web/oauth/current/msg02680.html

Do any of you have deployment experience with that feature yet?  There
is a proposal to drop it from the spec due to lack of deployment
experience.

I don't think we're going to end up using it, we're going to lean more
on HTML 5 instead.

Cheers,
Brian