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.
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.
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.
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.
Trong Huu Nguyen
