Fail at startup rather than on the first token request when the identity
provider does not accept the client assertion algorithm. The check is
skipped when the provider omits the field, which is optional in Discovery.
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.
The metadata document was fetched with http.Get, which has no deadline,
so a hung connection blocked startup indefinitely. The response status
was never checked either, leaving an error page to surface as a JSON
decoding error.
The fetch now runs with a 10s deadline derived from the context passed
in from main, goes through the shared transport so it is traced and
pooled, and rejects any non-200 response.
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.
Access Tokens are not necessarily JWTs. We also don't
have to validate them as we only pass it on as an opaque
string.
This also means that we don't log the JTI access tokens
anymore.
We also simplify handling of oidc callbacks.
There's a bunch of changes here, but in essence:
- split out openid configuration
- separate openid configuration between client/rp and provider
- consolidate client and provider related code in separate packages
These changes allow for simplification of the Handler, as well as a
bunch of test/mock code as the configuration is now instantiated
seperately from the client/provider code.
Trong Huu Nguyen
