Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

[Mike Jones <[e-mail]>]

All of Marius, Breno, Nat, myself, and several others on the OpenID AB list have read it this way.  I believe that either this change needs to be removed (my preference!) or a sentence needs to be explicitly added that states that "The same client_id MAY be used with both the code and token response types"  to explicitly rule out this apparently common misinterpretation of the new text.

Otherwise, I agree that it will continue to be perceived by most people as a breaking change.

				-- Mike

P.S.  When you make this change, you should also correct the typo in this sentence: "The authorization server MAY provider tools to manage such complex clients through a single administration interface" by changing "provider" to "provide".

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Eran Hammer
Sent: Wednesday, March 14, 2012 11:35 AM
To: Marius Scurtescu
Cc: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

You are not reading it correctly.

This is a *registration* requirement, meaning, the client has to inform the server of the different components. If the server doesn't care, it can issue one client identifier capable of both.

This protocol assume the authorization server asked the client for its type and based on that made decisions about the credentials issued and the security properties of the client. It is also triggers a whole list of normative language handling the different client types throughout the specification.

EH

> -----Original Message-----
> From: Marius Scurtescu [mailto:[e-mail]]
> Sent: Wednesday, March 14, 2012 11:24 AM
> To: Eran Hammer
> Cc: Breno de Medeiros; OAuth WG
> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> 
> Before v23 a web server client could use either response_type=code or 
> response_type=token, with the same client id. No security issues and 
> this was supported for quite a while.
> 
> With this latest change, if I am reading it correctly, this is not 
> possible anymore. The client has to use two different client ids. It 
> is very late in the game to introduce changes like this, unless there 
> is an extremely good reason.
> 
> Marius
> 
> 
> 
> On Wed, Mar 14, 2012 at 11:09 AM, Eran Hammer <[e-mail]>
> wrote:
> > If the server locks a client type to a particular grant type (or 
> > response type)
> then this is true, you don't need to specify the response type in the request.
> But this is based on a very limited set of potential response types. I 
> can envision a code response type with different response syntax but 
> same security properties, and same goes for token.
> >
> > In the past, a cookie response type was proposed to use the cookie
> headers in the server response instead of returning a token. The 
> security properties of such a flow are very similar to those of token 
> (from OAuth's perspective). This means a public client would be able 
> to request either token or cookie response type.
> >
> > Also as noted, servers are allowed to provide different registration 
> > options
> to clients, as long as the client identifies each discrete component. 
> There is no requirement or even suggestion that the server issues 
> different client identifiers to such complex clients. I think this is 
> another point missed in your reading of the text.
> >
> > Hope this clarifies it.
> >
> > EH
> >
> >> -----Original Message-----
> >> From: Breno de Medeiros [mailto:[e-mail]]
> >> Sent: Wednesday, March 14, 2012 10:16 AM
> >> To: Eran Hammer
> >> Cc: Marius Scurtescu; OAuth WG
> >> Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >>
> >> Can you explain to me why response_type is necessary at all after 
> >> this change.
> >>
> >> If a javascript client (candidate for token usage) and the web 
> >> server component (candidate for code usage) cannot share 
> >> registration (since they are different components with different 
> >> security contexts of the same
> >> application) then there is no need to specify response_type. The 
> >> server can infer the response type from the client and its security context.
> >>
> >> My objection has nothing to do with code+token flow. I think the 
> >> change makes response_types irrelevant and is essentially a new
> protocol.
> >>
> >> As far as I understand it, the introduction of different code and 
> >> token flows was precisely to allow different security-context 
> >> components of the same client to securely operate under the same 
> >> registration. I think if we change this we need to specify a lot 
> >> more behavior, such as how a client can request authorization on 
> >> behalf of
> several components simultaneously.
> >>
> >> On Wed, Mar 14, 2012 at 10:08, Eran Hammer <[e-mail]>
> >> wrote:
> >> > This was already raised and addressed on this list last week.
> >> >
> >> > When someone defines and registers code+token, that specification 
> >> > must
> >> define how such a client is registered in light of the text below.
> >> This might mean defining a new client type, choosing the 
> >> confidential client type with other normative text limiting the use 
> >> of the secret in the public component, etc.
> >> >
> >> > IOW, this section doesn't break anything because there is nothing 
> >> > else
> >> defined to break. There is no way to avoid explicitly defining 
> >> these requirements for a code+token response type, or any other new 
> >> response type for that matter. The text below is required to ensure 
> >> that the authorization server can properly enforce the rest of the 
> >> normative security language in the specification.
> >> >
> >> > EH
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: [e-mail] [mailto:[e-mail]] On 
> >> >> Behalf Of Marius Scurtescu
> >> >> Sent: Wednesday, March 14, 2012 9:53 AM
> >> >> To: OAuth WG
> >> >> Cc: Breno de Medeiros
> >> >> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> >> >>
> >> >> Hi,
> >> >>
> >> >> Nat Sakimura started a thread on the OpenID Connect list about a 
> >> >> breaking change introduced by rev 2.3
> >> >>
> >> >> The paragraph in question is in section 2.1:
> >> >>
> >> >> "A client application consisting of multiple components, each 
> >> >> with its own client type (e.g. a distributed client with both a 
> >> >> confidential server-based component and a public browser-based 
> >> >> component), MUST register each component separately as a 
> >> >> different client to ensure proper handling by the authorization 
> >> >> server.  The authorization server MAY provider tools to manage 
> >> >> such complex clients
> >> through a single administration interface."
> >> >>
> >> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-
> >> >> oa
> >> >> uth
> >> >> -v2-
> >> >> 23.txt
> >> >>
> >> >> You can see the thread here:
> >> >> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
> >> >> 20120312/001672.html
> >> >>
> >> >> This paragraph basically prevents response_type=code+token which 
> >> >> is already implemented by many providers and also relied on by 
> >> >> OpenID Connect.
> >> >>
> >> >> The intent, I think, was to prevent clients from embedding the 
> >> >> client secret meant for a confidential client into a public client.
> >> >> JavaScript based clients using the token flow do not need the 
> >> >> client secret, so this concern does not apply.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> Thanks,
> >> >> Marius
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >> --
> >> --Breno
_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth