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

[Eran Hammer <[e-mail]>]

Let's take a step back for a second.

Previous versions of this document stated that during the registration process the client developer specifies the client type as described in 2.1. This has been specified under "registration requirements" since -17 published July 8th 2011. The only two types provided were (and still are) public and confidential.

While there was no MUST or SHALL directive, the text was pretty clear about the need for each client registration to be tied to a single client type.

-23 was an attempt to clarify this, by making it explicit that hybrid clients are not addressed by the specification, and have to be dealt with as two separate clients.

The specification breaks if a client has more than one type. The authorization server cannot enforce some of the security requirements if the client type is unknown. This is all based on how the specification is written and how the security consideration section is structured.

The real issue raised here is how to handle hybrid clients which are beyond the scope of this specification.

Here is an alternative text:

   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, unless the authorization
   server provides other registration options to specify such complex clients.

It's basically saying that unless the authorization server provides a special option other than 'public' and 'confidential', clients MUST register such applications separately for each component. It leaves the decision of how to deal with such clients completely up to the authorization server during the registration process.

I think we should also add a SHALL in section 2: "When registering a client, the client developer SHALL:", which is implicit already.

Another, less desirable alternative is to remove this section and add:

   The authorization server MAY provide the client with other client types
   options during the registration process. Such client types are beyond the
   scope of this specification. Such additional client types will require a
   different set of security considerations not provided by this specification.

My intention was never to introduce a (breaking) change here, just to clarify what was already the prescribed process. I'm open to other suggestions as long as they account for the deep dependency this protocol has on client type identification.

EH



> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Wednesday, March 14, 2012 11:42 AM
> To: Eran Hammer; Marius Scurtescu
> Cc: Breno de Medeiros; OAuth WG
> Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
> 
> 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
>