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

[Eran Hammer <[e-mail]>]

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-oauth
> >> -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