Follow-up from the #10 security review.
nova_auth_oidc_jwt's ?ALLOWED_ALGORITHMS is hardcoded to RS256/384/512, ES256/384/512. None of asobi's four supported providers (Google, Apple, Microsoft, Discord) are affected - they sign ID tokens with RS256 (Apple's ES256 usage is the client-secret JWT, not the ID token). But this is a general-purpose library: Keycloak 24+ supports EdDSA, and both Keycloak and Authentik (this repo's own test fixture issuer) can be configured for PS256. A consumer on such a setup gets a total auth outage reported as no_matching_key, which misleadingly points the operator at their JWKS rather than the algorithm list.
Recommend:
- Add
PS256/384/512 to the default allowlist (same RSA keys, strictly stronger padding, no alg-confusion risk added).
- Expose the allowlist as an optional per-provider (or global) config key so a consumer can opt into EdDSA or a narrower list.
Explicitly do NOT derive the allowlist from the discovery document's id_token_signing_alg_values_supported the way oidcc_token:validate_id_token/3 does - a sloppy or compromised discovery response advertising HS256 would reopen the alg-confusion attack #10's allowlist exists to close. The list must stay a static, code-owned value (possibly config-overridable), never dynamically discovered.
Follow-up from the #10 security review.
nova_auth_oidc_jwt's?ALLOWED_ALGORITHMSis hardcoded toRS256/384/512, ES256/384/512. None of asobi's four supported providers (Google, Apple, Microsoft, Discord) are affected - they sign ID tokens with RS256 (Apple's ES256 usage is the client-secret JWT, not the ID token). But this is a general-purpose library: Keycloak 24+ supports EdDSA, and both Keycloak and Authentik (this repo's own test fixture issuer) can be configured for PS256. A consumer on such a setup gets a total auth outage reported asno_matching_key, which misleadingly points the operator at their JWKS rather than the algorithm list.Recommend:
PS256/384/512to the default allowlist (same RSA keys, strictly stronger padding, no alg-confusion risk added).Explicitly do NOT derive the allowlist from the discovery document's
id_token_signing_alg_values_supportedthe wayoidcc_token:validate_id_token/3does - a sloppy or compromised discovery response advertising HS256 would reopen the alg-confusion attack #10's allowlist exists to close. The list must stay a static, code-owned value (possibly config-overridable), never dynamically discovered.