Current behaviour

When authenticating via RH SSO in the developer portal the IdP responds to the /auth request with a 307 redirect which then triggers the browser to make a GET request to the /callback endpoint. This means all the parameters are sent in the URL making some visible in the browser. This can present a privacy concern as some of the parameters may contain Personally Identifiable Information.

Expected behaviour

The OAuth client in 3scale should read the supported_response_modes field from the response object returned by the OIDC discovery endpoint and if form_post is listed then use this as the default. This means that all parameters sent to the user-agent by the IDP will be in the body and so the browser will also send a POST to /callback URL and thus keep all params from being visible in the URL. This also then helps to prevent those same parameters being logged in the various parts of the infrastucture where this Personally Identifiable Information could potentially be tracked.

Tests carried out confirming the functionality

A simple test was performed to confirm that RH SSO supports the part of the OpenID Connect specification we are concerned with here.

The RH SSO server returns the OIDC discovery endpoint response object with the supported response modes as shown here:

response_modes_supported": [
        "query",
        "fragment",
        "form_post",
        "query.jwt",
        "fragment.jwt",
        "form_post.jwt",
        "jwt"
    ],

By intercepting the /auth request from 3scale during the login via RH SSO and adding the query parameter to the request:

GET /auth/realms/3scale/protocol/openid-connect/auth?client_id=devPortal&redirect_uri=https%3A%2F%2F3scale.apps-crc.testing%2Fauth%2Fkeycloak_1a86742e3952%2Fcallback&response_type=code&scope=openid&response_mode=form_post HTTP/1.1

We can see that RH SSO will respond with a POST request to the /callback endpoint:

POST /auth/keycloak_1a86742e3952/callback HTTP/1.1

...REDACTED...

code=30a0be45-2908-4fd5-b805-d2ed4fc1c168.683515b3-5ee2-4350-9a0b-651896346303.c104ddaf-a743-4a08-960a-467f90cfa336&session_state=683515b3-5ee2-4350-9a0b-651896346303

Notice above now how the code parameter is returned in the body via a POST.

This doesn't need to be a configurable option, simply that we read the supported_response_modes field and if present set form_post as the default and if not present then fall back to query (the current implementation) so that this will provide better user info privacy protection and not introduce any breaking changes. It is all part of the specification in any case.