-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Shibboleth Identity Provider Plugin Security Advisory [3 January 2022]

An updated version of the OpenID Connect OP plugin for the Shibboleth
Identity Provider is now available which corrects deficiencies in the
support for JWT-based client authentication to the token, introspection,
and revocation endpoints.

This issue is considered of "low" security importance to deployments,
and most deployments likely do not make use of this feature, but it is
enabled by default.

OpenID Connect OP plugin is missing required checks handling JWTs
======================================================================
The OAuth 2 (and OpenID Connect) specifications allow for a variety
of methods for an OAuth client (the relying party) to prove its identity
during API calls to the authorization server's token, introspection,
revocation endpoints.

By far the most common client authentication methods involve client
secrets (essentially just passwords), but the plugin includes support
for the two defined JWT-based methods, defined in section 9 of the
OpenID Connect Core specification [1]. The methods are referred to
as "client_secret_jwt" and "private_key_jwt".

These methods require some checks of the content of the JWT for
"appropriateness", in addition to the verification of the key used
to sign the JWT. Some of these checks are being performed by an
underlying library used by the plugin but a number of others are
missing, including checks for expiration and replay.

As a result, an attacker able to obtain a JWT token by compromising
the protected channel or the client would be able to make use of the
token to forge requests using it as an authenticator. The attacker
would still need to be able to obtain the actual data needed to
make such requests, such as short-lived authorization codes or
refresh tokens. Authorization codes are also checked for replay,
although this depends on having a shared storage model for full
protection.

Note that the signature checking _was_ being performed, so outright
forgery of a JWT itself is not possible via this flaw. In addition,
a separate bug prevented use of these methods from functioning on
any endpoint other than the token endpoint, further limiting exposure.

Recommendations
===============
Update to V3.0.3 or later of the OIDC OP plugin, which is now available.
The IdP's plugin installer can perform this update process.

In doing so, you may need to review and test any use of JWTs to ensure
they conform to the specification now that additional checking is done.

If you are not making use of this feature, consider leveraging the
two supported properties to globally disable use of the JWT methods
(idp.oidc.tokenEndpointAuthMethods, idp.oidc.dynreg.tokenEndpointAuthMethods).

Credits
=======
This issue was discovered by the Shibboleth Project team itself.

[1] https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20220103.txt
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3KoVAHvtneaQzZUjN4uEVAIneWIFAmHTBc4ACgkQN4uEVAIn
eWJUpxAAgtddPzAROIr2N9M4rbKgjLXhjqTcKilEcg13wBm8A/bT6DjzphZbtNUz
YwDWFFMbXrs5C8Rj1AOa0nobR9D28Sa8t6T+o4PRtjR9Dwx3MkVrsksDRQToOvJR
OC4kgdqEtmMgm5Mk4SBvw13XkCvPrWTcQMHG3Rm24xz1btCO65pNUxLZixV5IsBO
HO3zCLwBtDC7CMMFfG9DBArpnQyghaIXiYhrmszaL6H/FbQyuAE66HtW91hEy1dh
vL3l6+2xZTtd8UDnQfIWwUF0icpS2T/CcGXF/vaZqIzDTgOeHf/DWX2tCcou7szj
8dNRUV8RApp58g7Iil0RI8+sqdNrrciiO63H2e/92k4ePaLz28fcDhdV+4Ntkp17
4bBfsIhM2LZwKDnqc+R5CyybZHm7gcGYDr8LABXrpybccrXCG5sfskQVKMnvKopq
653jIHpScbogCZ/jMslS+JU7NnxLwNq/wg7H399iX84lMPMa7qdkooV75dYP9z8W
AZo+N5S+27QbIgBo9Wz741hH9tegX4TVOqweVJZPZbFDuNRh37c3PYMFUWi4lPFC
aim3jc/vtxX+st61YjR5N3JgtRO1CXqk4riLcZfnIMNJ7kNpa2WYiz0416ESRuQy
/09PyfbLaGJJnW5LPFU5oz475MRgOC3C775pJt34klem3isMPPE=
=4R8V
-----END PGP SIGNATURE-----