Agreed, servers could enforce that combinations that don't make sense result in
errors.
BTW, OpenID Connect decided to keep both parameters for registration, since
they're not actually orthogonal. While verbose, at least then the registration
information about what grant types and response types the client is choosing to
limit itself to using can be accurate.
We also decided that if these parameters are omitted, the default values are
"code" and "authorization_code".
Best wishes,
-- Mike
From: Justin Richer [mailto:[email protected]]
Sent: Thursday, February 28, 2013 7:42 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: [OAUTH-WG] Registration: grant_types and response_types
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
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 protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Justin Richer
Sent: Wednesday, February 27, 2013 8:00 AM
To: [email protected]<mailto:[email protected]>
Subject: [OAUTH-WG] Registration: grant_types and response_types
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
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>.
* "password": The Resource Owner Password Credentials Grant
described in OAuth2 Section
4.3<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.3>
* "client_credentials": The Client Credentials Grant described in
OAuth2 Section
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 OAuth2 Section
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 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 protected]
https://www.ietf.org/mailman/listinfo/oauth
