RemoveKey shifts later keys into the removed index, so a forward loop skipped
the key after each removal. Two adjacent alg=none keys left the second one in
the set handed to signature verification.
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.
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.
Requests to the token and pushed authorization endpoints carry the
client secret or a signed client assertion. Following a redirect would
forward those credentials to a host the provider never advertised.
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`.
While RFC 6749 specify this field as recommended:
> If omitted, the authorization server SHOULD provide the
> expiration time via other means or document the default value.
and equivalently the OIDC Core spec specifies the same field as optional,
we will explicitly enforce that these fields are returned from the AS.
This isn't a breaking change as the existing session refresh logic implicitly
depends on this field and its value.
While there are probably some providers that omit the `expires_in` field
or sets it to zero with the intent of returning access tokens that do not
expire, we assume these are relatively rare. We might revisit this
at some point in the future, should our assumptions be wrong.
In accordance with OpenID Connect 1.0 Core, draft 36 incorporating
errata set 3:
> aud
> REQUIRED. Audience. The aud (audience) Claim. [...] The Audience value MUST be the OP's Issuer Identifier passed as a string, and not a single-element array.
Instead of erroring when receiving non-empty, invalid parameters, we fall back to
the configured (if any) default value for the identity provider, which
is already validated with its metadata document on start-up.
This prevents end-users from being exposed to unnecessary errors.
Trong Huu Nguyen
