Make discovery grant and response types configurable #924

Preflight checklist

• I could not find a solution in the existing issues, docs, or discussions.
• I have joined the ZITADEL chat.

Describe the problem

pkg/op/discovery.go currently hardcodes these authorization server capabilities:

• ResponseTypes always returns code, id_token, and id_token token.
• GrantTypes always starts with authorization_code and implicit.

A self-hosted deployment can disable implicit and ID-token authorization responses on every registered client, but its discovery document still advertises them. There is no provider configuration that removes those capabilities globally.

This is not a client authorization bypass. Clients that only allow code correctly reject response_type=id_token and response_type=id_token token with unauthorized_client. The problem is that the server metadata overstates the deployment policy, and operators cannot publish code-only metadata without maintaining a fork or rewriting the discovery response at a reverse proxy.

OAuth 2.0 Security Best Current Practice recommends authorization code instead of responses that issue tokens from the authorization endpoint. Some security reviews also require discovery metadata to match the enabled deployment policy.

Relevant code:

• https://github.com/zitadel/oidc/blob/main/pkg/op/discovery.go
• ResponseTypes includes a TODO about making the values dynamic.

Describe your ideal solution

Add provider configuration for server-wide supported response types and grant types, with current behavior as the backwards-compatible default.

When configured as code-only:

1. Discovery returns response_types_supported: ["code"] and does not advertise implicit.
2. Authorization requests using id_token or id_token token are rejected at the provider level, even if a client is accidentally configured to allow them.
3. The same configuration drives metadata and request validation so they cannot drift.
4. Existing deployments that do not set the new options retain the current defaults.

A possible API would add SupportedResponseTypes and SupportedGrantTypes to provider configuration, then have both discovery generation and authorization request validation consume them.

Version

Observed with github.com/zitadel/oidc/v3 v3.47.5 in current ZITADEL main. The hardcoded behavior is also present on the current zitadel/oidc main branch.

Environment

Self-hosted

Additional context

• RFC 8414 defines these discovery fields as the grant and response types supported by the authorization server: https://www.rfc-editor.org/rfc/rfc8414.html#section-2
• RFC 9700 recommends authorization code instead of implicit responses that expose access tokens in the authorization response: https://www.rfc-editor.org/rfc/rfc9700.html#section-2.1.2

We currently enforce code-only behavior per client and have live negative tests for both ID-token response types. Configurable server-wide enforcement would remove the need for a discovery rewrite at the edge and protect against future client misconfiguration.