OAUTH 2.0 Signature algorithm for REST OIDC AuthenticationDescriptionConsidering the list algorithms mentioned in below link, what are all the Algorithms that we support for REST Inbound API using OAUTH 2.0 in ServiceNow other than RS256? https://techdocs.broadcom.com/us/en/ca-enterprise-software/layer7-api-management/api-gateway/9-4/policy-assertions/assertion-palette/xml-security-assertions/generate-security-hash-assertion.htmlRelease or EnvironmentAllInstructionsPlatform uses Nimbus library for JWT validation and BC library for OIDC. In Quebec, we were using lib "nimbus-jose-jwt" version 6.7 however, in Rome, we upgraded the lib "nimbus-jose-jwt" version to 9.7 as a security enhancement. These are list of algorithm we supported: https://connect2id.com/products/nimbus-jose-jwt/jca-algorithm-supportJWS algHS256, HS384, HS512RS256, RS384, RS512PS256, PS384, PS512ES256, ES384, ES512, ES256K Please note, Nimbus Library v6.7 supports ID token (JWT) obtained from external OIDC Provider where the type is "at+jwt" whereas Nimbus Library v9.7 doesn't allow such JWT token typ. It only allows token of typ "JWT" by default. You can see this information by decoding a JWT token in a website "https://jwt.io/", there you will see that the decoded header has a claim "typ": "at+jwt" or "jwt". Because Nimbus Library v9.7 missing this backward compatibility therefore after upgrading to ROME or higher releases, it will cause an ID token (JWT) validation failure if claim "typ" is "at+jwt". Also please note, OIDC specifications doesn't say about such tokens therefore, this does not appear to be a right way to use such tokens in OIDC flow.When looking further about tokens with "typ":"at+jwt", these are access token issued in the form of JWT format. These are different from the ID_Tokens, which are expected in the OIDC protocol. https://www.iana.org/assignments/media-types/application/at+jwt As per OIDC protocol, client should request ID_token from Authorization server. This should be requested via OAuth Authorization grant with the added scope of "openid" and obtaining end_user consent.We have seen cases where customer used client_credential to obtain JWT token. And the token server responded with Access Token of JWT format (which is different from ID token as mentioned above). And hence we didn't think it is valid use-case in OIDC protocol. Just saw through this customer. As a fix, please follow-up with your OIDC provider to generate an OIDC token of type "JWT" instead of "at+jwt" (Meaning the customer's OIDC provider's generated token should have a header claim as "typ": "JWT" instead of "typ": "at+jwt").