response_types_supported looks incorrect

[mkontani]

Thanks for useful tool. I want to confirm about response_types_supported.

For example, I think that if we set responseTypes '["code", "token"]' on configfile, '.well-known/openid-configuration's response_types_supported should be configured like '["code", "token", "code token"]', but current is configured like '["code", "token"]'.

In other ward, current is set response_types_supported only single type.
Is there any reason? Im sorry if it's my misunderstanding.

Thanks.

[srenatus]

You're probably correct. The spec isn't explicit here, I think:

response_types_supported
REQUIRED. JSON array containing a list of the OAuth 2.0 response_type values that this OP supports. Dynamic OpenID Providers MUST support the code, id_token, and the token id_token Response Type values.

...but in its example, it includes the concatenated strings like you suggested:

"response_types_supported":
  ["code", "code id_token", "id_token", "token id_token"],

Anyways, I think the openid-configuration output could be improved, see also #1209.

[mkontani]

@srenatus Thank you for confirmation!

In rfc6749, response_type can be set only one "code" or "token".
After OIDC defined, it became possible to set multiple response_type in any combination. (spec)

code token
When supplied as the value for the response_type parameter, a successful response MUST include an Access Token, an Access Token Type, and an Authorization Code. The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode.
code id_token
When supplied as the value for the response_type parameter, a successful response MUST include both an Authorization Code and an id_token. The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode.
id_token token
When supplied as the value for the response_type parameter, a successful response MUST include an Access Token, an Access Token Type, and an id_token. The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode.
code id_token token
When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code, an id_token, an Access Token, and an Access Token Type. The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode.

Now dex looks support multiple response_type in any combination.
https://github.com/dexidp/dex/blob/master/server/handlers.go#L565-L650

[Timost]

Hi,
Thank you for dex ! 🙏

I know this is an old issue, but I have stumbled on an OIDC client minio/console (minio/console@fb99cf3) which checks the supported response types.

Although dex supports the code id_token flow, it doesn't advertise so in the discovery endpoint so the preflight checks fail on minio/console's side.

I hot fixed with:

diff --git a/server/oauth2.go b/server/oauth2.go
index 23f06b82..02014eda 100644
--- a/server/oauth2.go
+++ b/server/oauth2.go
@@ -133,9 +133,10 @@ const (
 )

 const (
-       responseTypeCode    = "code"     // "Regular" flow
-       responseTypeToken   = "token"    // Implicit flow for frontend apps.
-       responseTypeIDToken = "id_token" // ID Token in url fragment
+       responseTypeCode        = "code"     // "Regular" flow
+       responseTypeToken       = "token"    // Implicit flow for frontend apps.
+       responseTypeIDToken     = "id_token" // ID Token in url fragment
+       responseTypeHybridToken = "code id_token"
 )

 const (
diff --git a/server/server.go b/server/server.go
index 6b653fdb..9a2f1867 100755
--- a/server/server.go
+++ b/server/server.go
@@ -216,7 +216,7 @@ func newServer(ctx context.Context, c Config, rotationStrategy rotationStrategy)
        supportedRes := make(map[string]bool)
        for _, respType := range c.SupportedResponseTypes {
                switch respType {
-               case responseTypeCode, responseTypeIDToken, responseTypeToken:
+               case responseTypeCode, responseTypeIDToken, responseTypeToken, responseTypeHybridToken:
                default:
                        return nil, fmt.Errorf("unsupported response_type %q", respType)
                }

But do you think it would be worth adding support for this ?