feat(openid-connect): make client_secret optional for local JWT verification modes

[AlinsRan]

Background

Closes #10563
Closes #13397

In service-to-service scenarios where the gateway only validates an incoming Bearer token locally (via a configured public key or JWKS endpoint), client_secret plays no role — no call is made to the IdP's token or introspection endpoint. However, the plugin currently requires client_secret unconditionally, forcing users to supply a dummy value as a workaround.

Changes

apisix/plugins/openid-connect.lua

• Remove client_secret from the schema's required array.

• Add conditional enforcement in check_schema: client_secret is still required for all flows that need it (session/callback flow, introspection), but is now optional when:

  • bearer_only=true + public_key: local JWT verification with a configured public key
  • bearer_only=true + use_jwks=true: local JWT verification via JWKS endpoint
  • token_endpoint_auth_method=private_key_jwt: RSA private key replaces client_secret
  • use_pkce=true (non-bearer): public-client PKCE flow

• Fix claim_schema not being enforced in the bearer-token path (openid-connect: claim_schema is not enforced in the bearer-token authentication path #13397): the schema is now applied directly to the flat JWT payload / introspection response in the bearer branch.

t/plugin/openid-connect.t

Add TEST 42–47 covering:

• bearer_only=true + public_key → no client_secret required
• bearer_only=true + use_jwks=true → no client_secret required
• bearer_only=true + introspection endpoint (no local key) → client_secret still required
• token_endpoint_auth_method=private_key_jwt → no client_secret required
• use_pkce=true → no client_secret required
• Session flow without special auth method → client_secret still required

Backward Compatibility

All existing configurations remain valid. The change only relaxes the requirement for specific scenarios; any config that previously worked continues to work unchanged.

[membphis]

[P2] The client_secret alternatives need to be scoped to the OIDC flow they actually replace.

The final schema-level anyOf accepts any of public_key, use_jwks, use_pkce, introspection_endpoint_auth_method=private_key_jwt, or token_endpoint_auth_method=private_key_jwt as a global replacement for client_secret. That is broader than the intended behavior: some alternatives only apply to bearer/local JWT verification, some only to bearer introspection, and some only to the non-bearer token endpoint flow.

For example, a bearer introspection config without client_secret can currently pass schema validation if it sets token_endpoint_auth_method=private_key_jwt, even though that field is not the auth method used for introspection. Similarly, a non-bearer session flow can be accepted via an alternative that is only meaningful for bearer validation.

Please either restore the mode-aware validation in check_schema, or express the condition in JSON Schema with bearer_only/flow-specific branches. It would also be good to add negative tests for cross-flow combinations, e.g. bearer_only=true + introspection + token_endpoint_auth_method=private_key_jwt without client_secret, and non-bearer session flow with an introspection-only alternative.

[AlinsRan]

@membphis Thanks for catching this. You're right that the global anyOf was too broad — it accepted cross-flow combinations where the alternative does not apply to the actual flow.

I've reverted the schema-level anyOf and restored the mode-aware validation in check_schema, scoping each exemption to its flow:

• bearer_only=true: exempt only via public_key/use_jwks (local JWT verification) or introspection_endpoint_auth_method=private_key_jwt (introspection auth)
• non-bearer (session/callback): exempt only via token_endpoint_auth_method=private_key_jwt or use_pkce

Also added negative tests for the cross-flow cases you mentioned:

• bearer_only=true + introspection + token_endpoint_auth_method=private_key_jwt without client_secret → now rejected
• non-bearer session flow with a bearer-only alternative (introspection private_key_jwt) without client_secret → now rejected