Subject: [OAUTH-WG] Registration: grant_types and response_types

From: Justin Richer <[email-masked]>
Date: Wed, 27 Feb 2013 10:59:59 -0500

There has been some press lately about clients being able to use an 
implicit flow to get tokens when they really ought to only use a code 
flow, since the security considerations and protections for both are 
very different. With this in mind, it makes sense that a dynamically 
registered client should be limited to use only certain flows, if at all 
possible.

The dynamic registration document currently handles this using the 
grant_type parameter (introduced in draft -03), which is defined in 
section 2 as follows:

    grant_type
       OPTIONAL.  Array of grant types that a client may use.  These
       grant types are defined as follows:

       *  "authorization_code": The Authorization Code Grant described in
          OAuth2Section 4.1  <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.1>.

       *  "implicit": The Implicit Grant described in OAuth2Section 4.2  <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.2>.

       *  "password": The Resource Owner Password Credentials Grant
          described in OAuth2Section 4.3  <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.3>

       *  "client_credentials": The Client Credentials Grant described in
          OAuth2Section 4.4  <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.4>

       *  "refresh_token": The Refresh Token Grant described in OAuth2
          Section 6  <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-6>.

       Authorization Servers MAY allow for other values as defined in
       grant type extensions to OAuth2.  The extension process is
       described in OAuth2Section 2.5  <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-2.5>, and the value of this parameter
       MUST be the same as the value of the "grant_type" parameter
       defined in the extension.

This allows the client to specify which flows it wants to be able to use 
(including any extensions), and allows the server to to tell the client 
in the client configuration response what flows it can expect to work.

OpenID Connect's registration has recently introduced the use of a 
different parameter, response_type, for a similar but slightly different 
purpose. The parameter is defined in the latest draft in source control as:

    response_types
        OPTIONAL. JSON array containing a list of the OAuth 2.0
        response_type
        values that this Client uses. If omitted, the default is that
        the Client
        uses only the coderesponse type. 

OIDC makes use of response_types beyond just "code" and "token", 
defining several new ones including combinations like "code idtoken".

So my question to the group is this: Should we incorporate the OIDC 
response_types parameter? Do we need both parameters specified in the 
registration or is one sufficient? They're defined separately in the 
OAuth2 protocol (one is on the Auth endpoint and one is on the Token 
endpoint), but can only be used legally in particular combinations so 
there would have to be normative text around particular values.

In my opinion, I don't think we can get rid of grant_type, since that's 
the only way to specify things like client_credentials flows and most 
extensions. There might be value in also specifying response_type, but I 
don't want to add extra fields unless there's a clearly defined need for it.

  -- Justin

---

From: John Bradley <[email-masked]>
Date: Wed, 27 Feb 2013 08:47:50 -0800

For grant_type you have to make up implicit as a grant_type. 

They are sort of separate things and are both extendable in the case of assertions for the token endpoint, and new response types like "code id_token" or "token code" for response type. 

Both could be used to not allow implicit but also have other value. 

I would like to combine them, but that may be more confusing than directly mapping them to the OAuth functionality. 

It may be sufficient to have response_type and grant_type in discovery but only grant_type in registration. 

We need to agree on what grant_type/s are required for a response_type of "code id_token" that is returned in a fragment but uses the token endpoint. 

John B. 

Sent from my iPhone

On 2013-02-27, at 7:59 AM, Justin Richer <[email-masked]> wrote:

> There has been some press lately about clients being able to use an implicit flow to get tokens when they really ought to only use a code flow, since the security considerations and protections for both are very different. With this in mind, it makes sense that a dynamically registered client should be limited to use only certain flows, if at all possible. 
> 
> The dynamic registration document currently handles this using the grant_type parameter (introduced in draft -03), which is defined in section 2 as follows:
> 
>    grant_type
>          OAuth2 Section 4.1.
>       *  "implicit": The Implicit Grant described in OAuth2 Section 4.2.
> 
>          described in OAuth2 Section 4.3
> 
>          OAuth2 Section 4.4
>          Section 6.
>       described in OAuth2 Section 2.5, and the value of this parameter
> This allows the client to specify which flows it wants to be able to use (including any extensions), and allows the server to to tell the client in the client configuration response what flows it can expect to work. 
> 
> OpenID Connect's registration has recently introduced the use of a different parameter, response_type, for a similar but slightly different purpose. The parameter is defined in the latest draft in source control as:
> 
> response_types
> OPTIONAL. JSON array containing a list of the OAuth 2.0 response_type 
> values that this Client uses. If omitted, the default is that the Client 
> uses only the code response type.
> 
> OIDC makes use of response_types beyond just "code" and "token", defining several new ones including combinations like "code idtoken". 
> So my question to the group is this: Should we incorporate the OIDC response_types parameter? Do we need both parameters specified in the registration or is one sufficient? They're defined separately in the OAuth2 protocol (one is on the Auth endpoint and one is on the Token endpoint), but can only be used legally in particular combinations so there would have to be normative text around particular values.
> 
> In my opinion, I don't think we can get rid of grant_type, since that's the only way to specify things like client_credentials flows and most extensions. There might be value in also specifying response_type, but I don't want to add extra fields unless there's a clearly defined need for it.
> 
>  -- Justin
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Wed, 27 Feb 2013 22:52:16 +0000

John Bradley and I just talked about this during a side meeting at RSA.  We think that this is the mapping of grant types and defined response types.  (The additional response_type values are registered with IANA and defined in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html.)

response_type value

grant_types

code

authorization_code

token

implicit

id_token

implicit

token id_token

implicit

code token

authorization_code implicit

code id_token

authorization_code implicit

code token id_token

authorization_code implicit

none

none

If people agree that this is the mapping, and that it conveys sufficient information, then conceivably OpenID Connect could drop the response_types registration parameter and instead just use the OAuth Registration "grant_types" parameter.

What do others think?

                                                            -- Mike

P.S.  There's a typo in the OAuth Registration spec section quoted below.  The name "grant_type" should have been "grant_types", since the value is a list.  We should correct that in the next version of the spec.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, February 27, 2013 8:00 AM
To: [email-masked]
Subject: [OAUTH-WG] Registration: grant_types and response_types

   grant_type

         OAuth2 Section 4.1<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.1>.

      *  "implicit": The Implicit Grant described in OAuth2 Section 4.2<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.2>.

         described in OAuth2 Section 4.3<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.3>

         OAuth2 Section 4.4<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.4>

         Section 6<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-6>.

      described in OAuth2 Section 2.5<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-2.5>, and the value of this parameter

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 28 Feb 2013 10:41:44 -0500

The good thing about having two fields is that they map to the two 
different parameter names directly. The trouble is that you could get in 
a situation where a client can't actually do anything, say if you 
register response type "token" and grant type "authorization_code". With 
a table like the one below, we can help developers see what the right 
mappings should be and help servers to enforce this.

Thoughts?

  -- Justin

On 02/27/2013 05:52 PM, Mike Jones wrote:
>
> John Bradley and I just talked about this during a side meeting at 
> RSA.  We think that this is the mapping of grant types and defined 
> response types.  (The additional response_type values are registered 
> with IANA and defined in 
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html.)
>
> *response_type value*
>
> 	
>
> *grant_types*
>
> code
>
> 	
>
> authorization_code
>
> token
>
> 	
>
> implicit
>
> id_token
>
> 	
>
> implicit
>
> token id_token
>
> 	
>
> implicit
>
> code token
>
> 	
>
> If people agree that this is the mapping, and that it conveys 
> sufficient information, then conceivably OpenID Connect could drop the 
> response_types registration parameter and instead just use the OAuth 
> Registration "grant_types" parameter.
>
> What do others think?
>
> -- Mike
>
> P.S. There's a typo in the OAuth Registration spec section quoted 
> below.  The name "grant_type" should have been "grant_types", since 
> the value is a list.  We should correct that in the next version of 
> the spec.
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Justin Richer
> *Sent:* Wednesday, February 27, 2013 8:00 AM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] Registration: grant_types and response_types
>
> registered client should be limited to use only certain flows, if at 
> all possible.
>
> This allows the client to specify which flows it wants to be able to 
> use (including any extensions), and allows the server to to tell the 
> client in the client configuration response what flows it can expect 
> to work.
>
> different parameter, response_type, for a similar but slightly 
> different purpose. The parameter is defined in the latest draft in 
> source control as:
>
> response_types
>
> In my opinion, I don't think we can get rid of grant_type, since 
> that's the only way to specify things like client_credentials flows 
> and most extensions. There might be value in also specifying 
> response_type, but I don't want to add extra fields unless there's a 
> clearly defined need for it.
>
>  -- Justin
>