Introduce OidcResponseFilter

[sberyozkin]

This PR introduces OidcResponseFilter to support filtering responses to all quarkus-oidc, quarkus-oidc-client and quarkus-oidc-client-registration calls. With OidcRequestFilter and OidcRedirectFilter already available, all the direct and indirect communication channels with the OIDC server can not be filtered.

I'll clean up and open for review early next week

• Fixes: Add OIDC response filters #42117.

[github-actions]

🙈 The PR is closed and the preview is expired.

[sberyozkin]

The main design challenge from my point of view is whether to allow response filters modify the response body by returning an updated Buffer or not. I think it can be a bit too flexible and I'm not aware right now of any use cases which might require it. Nor I'm aware of other APIs supporting the response body modification (JAX-RS ClientResponseFilter, etc) .

I can only imagine a case where a non-standard property name is used in the response, Quarkus OIDC does not recognize it, and the the filter transforms the body. But it can be controlled at the configuration level if necessary, modifying OIDC responses can introduce an unexpected immediate or later time error in the system.

So, right now, OidcResponseFilter can help to do specialized logging and do all sort of actions given the response status code, headers and body (send events, record some response data values somewhere, etc)

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 8736dc6.

✅ 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.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

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

✅ 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]

The other thing I've realized is that the request context properties visible to the request filters must be visible to the response filters to make them more useful.

For example, both for quarkus-oidc and quarkus-oidc-client, the refresh token grant response will be exactly the same in structure to the main grant's response. With quarkus.oidc, the authorization code flow response will return the id, access and refresh tokens; and so will the refresh token grant.

So being able to check in the response filter which grant was used to return the current tokens is important.
It also gives access to the tenant id, and other relevant properties.

[sberyozkin]

Overall though, the PR changes are simple, given the HttpResponse<Buffer>, get the Buffer, pass it, the headers, the status, and the request context properties to the response filters if any, and then use the original buffer to convert it to JSON or string as required, and this is really all to it.
Tests, docs, have been updated

@pedroigor, @gastaldi, please have a look when you get a chance

[sberyozkin]

Hi Pedro @pedroigor, how does it look to you ? The way OidcResponseFilter is controlled and optionally bound to specific endpoints only is done exactly the same way we discussed with you and did for OidcRequestFilter

[sberyozkin]

Hey @gastaldi @pedroigor, let me merge it now, it is indeed not really about the OIDC logic, so I believe George's approval is sufficient, thanks