Client assertion signing is algorithm-agnostic, but the fixtures only
produced RS256 keys, so nothing proved it. Covers RSA, ECDSA and Ed25519,
including both RFC 9864 identifiers.
Also drops a kty assignment that jwx ignores and that would have mislabelled
non-RSA keys had it taken effect.
Both the assertion signer and the provider validation derived the algorithm
from the key and had to handle a missing "alg" that NewClientConfig already
rejects. Validate it once at construction and keep the result.
The flag never described id_token verification. It assigns an algorithm to
provider JWKS keys that omit "alg", which is a compatibility shim for
providers such as Azure and ID-porten.
BREAKING CHANGE: openid.id-token-signing-alg is now openid.jwks-fallback-alg.
A config file with the old key fails to start. The old environment variable
is ignored and the value falls back to RS256.
Each finding was reviewed individually; the annotations record why the
flagged code is safe rather than suppressing the rules globally.
- G101: viper configuration keys, not credentials
- G117: the marshalled value is the plaintext input to the encryption
that immediately follows, or a token endpoint response that is
required to carry tokens
- G118: the background deletion must outlive the request, so the
request context deliberately is not used
- G124: cookie attributes are validated in config.Cookie.Validate
- G710: the redirect targets are relative by construction, validated by
the url validators, or read from the provider's metadata document
Satisfies errcheck. Errors that carry no actionable information are
ignored explicitly: writes to an already-committed response, and closing
a fully read response body or file.
Test fixture setup asserts with require.NoError instead, since a failure
there means the fixture itself is broken.
Some providers require that the `typ` header has a value exactly equal
to `client-authentication+jwt` in accordance with changes introduced by
RFC7523bis.
This commit allows for opting in to setting the `typ` header with this new value.
The default behaviour is to use the previous de facto standard value, `JWT`.
Once the changes in RFC7523bis lands in the affected standards and
identity providers start supporting the new `typ` header (Entra ID being
notable for not supporting this as of this commit), we will default to
use `client-authentication+jwt`.
This allows us to verify signatures without relying on heuristics used
by jws.WithInferAlgorithmFromKey() that may introduce security and
performance implications.
We no longer expect nor accept tokens with old acr values during
validation as ID-porten no longer issues tokens with these values.
This also removes backward compatibility in cases where configured
values targeted the new ID-porten while using old ID-porten.
We still maintain an internal mapping from old values to new values
for forward compatibilty when using old values provided in the login
parameter and the `openid.acr-values` flag.
Replace hardcoded callback URLs with dynamic generation
of URLs based on incoming requests. These are validated against
a pre-registered list of ingresses for which Wonderwall is considered
authorative for.
We also preserve the cookie behaviour; the most specific ingress path
and domain is used for the cookies.
The `url` package has been moved to the `handler` package, and its
implementation refactored slightly for readability and DRY.
Trong Huu Nguyen
