Accept signed OIDC UserInfo

[sberyozkin]

Fixes #42341.

Quarkus OIDC may request UserInfo from the OIDC provider, in addition to a signed ID token in the JWT format.
Typically, UserInfo is returned as a plain JSON.

However, the OIDC spec also allows returning signed UserInfo, i.e, as a JWT token:

https://openid.net/specs/openid-connect-core-1_0.html#UserInfo

To handle signed UserInfo, Quarkus needs to verify it like any other JWT token, and then get the UserInfo JSON out of this token.

So this PR does a simple enough fix to do it to meet this spec requirement:

• If a UserInfo response media type is application/jwt then a signed UserInfo JWT is expected and it goes through the same verification process that a regular JWT token such as IdToken is goes through. The only reason there is a bit of a copy and paste there is that with regular JWT tokens some requirements like enforcing the audience verification may be optional, while with the signed UserInfo it is required, while things like nonce and sub claims are not required.
• Once the JWT is verified, UserInfo is initialized with the secured JSON
• Updated one of the OIDC wiremock tests to return a signed UserInfo and to check the log to confirm that indeed it was the case, the signed UserInfo form only exists during the response from the OIDC server to Quarkus OIDC, so it is tricky to confirm it otherwise

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit c358c25.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[sberyozkin]

Thanks @gastaldi, let me merge, @pedroigor, please ping me if you have any questions, it is indeed only about detecting if UserInfo is wrapped in the JWT container and if yes, then extract it from it after verifying the JWT signature.

[airone-x1]

Hello,

My tests on version 3.14.0.CR1 are not conclusives, same error. The jwt response is not handled as such but as simple json.

The userinfo endpoint returns a content-type "application/jwt; charset=utf-8".
I see in changes a strict test on "application/jwt" (OIDCProvider.java), may be the reason.