OpenID Connect Error - "Signed JWT rejected" with CAS

Issue

When configuring authentication using OpenID Connect, login fails and the following error is reported:

Unable to validate tokens: Signed JWT rejected: Another algorithm expected, or no matching key(s) found

We have observed that the JWKS URL of CAS does not include the description of the algorithm (missing alg field) in the key in many default configurations described in online tutorials and documentation. Your JWKS URL probably looks like this:

{
  "keys": [
    {
      "kty": "RSA",
      "n": "[REDACTED]",
      "e": "AQAB"
    }
  ]
}

You should fix the JWKS URL output in CAS so that a specific algorithm is specified in the alg field. RS256 should be fine in most cases but you can select another value assuming it is supported both by CAS and the https://connect2id.com/products/nimbus-jose-jwt library Liferay uses to decode JWT tokens (mind the versions of CAS and Nimbus JOSE JWT).
How to update the configuration of CAS is beyond the scope of this fast track article. Check the Apereo CAS documentation to help you with that.
This is what your JWKS URL output should look like:

{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "n": "[REDACTED]",
      "e": "AQAB"
    }
  ]
}

In earlier versions of Liferay, there used to be another bug with the algorithm selection which has been fixed in the latest DXP 7.3 releases and in DXP 7.4: https://help.liferay.com/hc/en-us/articles/17201700314125-OpenID-Connect-Error-Signed-JWT-rejected
According to https://datatracker.ietf.org/doc/html/rfc7517#section-4.4, the alg field is optional. The absence of that field means that the OpenID Provider supports any algorithm. However, it is best practice to specify the algorithm so as to make sure that both the client and the OpenID Provider can understand each other. The Nimbus JOSE JWT library's approach is to explicitely look for a matching key and that is why it does not pick a key from the JWKS output if no alg is specified.
If the OpenID Provider does explicitely support multiple algorithms with the same key, the best practice is to output one key record per supported algorithm.
You can learn about the version of nimbus-jose-jwt used by Liferay by checking this gradle file: https://github.com/liferay/liferay-portal/blob/master/modules/apps/portal-security-sso/portal-security-sso-openid-connect-impl/build.gradle
We have only observed the absence of the alg field in Apereo CAS but it is possible that this behaviour exists with other less popular OpenID Providers we have not yet encountered. If that is the case, the solution is the same.