OAuth 2.0 Multiple Response Type

[azmeuk]

There has been an initial support for OAuth 2.0 Multiple Response Type Encoding Practices with #48.

It is implemented in a very ad-hoc way only for the OIDC implicit grant, and is not documented.

I suggest to move the implementation in a dedicated module, as an AuthorizationServer extension, and complete it. It should:

• handle the response_mode parameter for any grant, not just OIDC implicit. Support for query and fragment.
• support multiple response_type values
• implement the id_token response_type value (strangely for a OAuth2 spec, it overlaps with OIDC)
• implement the none response_type value.
• forbid the query response_type value with token and id_token response types.

[azmeuk]

I have been thinking about the design for this. There might be things to settle about exception management.
According to rfc6749:

• on the authorization endpoint
  • some errors (invalid_request with invalid redirect_uri, unauthorized_client, unsupported_response_type) should directly be displayed by the authorization server, and not be part of the endpoint response to the end-user browser,
  • the other errors should be part of the response endpoint to the end-user browser
• on the other endpoints (such as the token endpoint) the responses (including the error responses) are returned in JSON to the client.

The RFC6749 only describe the query response mode, without naming it since the response_mode concept is described in OAuth 2.0 Multiple Response Type Encoding Practices.
This spec details the query and fragment response modes, that return the payload in the the query or fragment part of an url redirection to the client callback endpoint. Other specs such as #48 don't use redirections, but a regular 200 page displaying a form that is auto-validated with Javascript, and submitted to the client callback endpoint.

Currently RFC6749 only manages error in 302 redirections when the redirect_uri parameter is passed to the exception object, and this is raised to be catched by the web framework implementation if redirect_uri is not defined. To correctly handle the other response types (such as 200 pages), we should refactor this part, and not assume that every error response is a 302. This will probably involve a generic layer for responses, that will be catched by rfc6749 to be transformed as a redirection, and later catched by OAuth 2.0 Multiple Response Type Encoding Practices if enabled, and then transformed as the response_mode defines it.