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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
