[Bug] Callback redirect fails when using PUBLIC_URL and OIDC together (incomplete auth standard workflow with keycloak)

[alej4ndro]

Describe the Bug

Hello,

The issue is somehow similar to a recurrent problem reported in old issues: #2263, #1125, #1925, #2695. But I guest is essentially the same problem reported at #2540, #2850 (tested both with master branch and with tag v3.7.0).

When configuring OIDC as here to work with keycloak, and at the same time using a PUBLIC_URL and editing routerBasename as explained here, the authentication process is unable to work properly. It performs the auth request to keycloak and then is redirect to the callback page, but subsequent calls to keycloak token endpoint never happens:

Debugging a bit, I found that the problem occurs here, due to when routerBasename is modified pathname and redirect_uri do not match and the intended use case for that if does not work:
.

It happens only when routerBasename is different than '/'. In case of routerBasename = '/' (regardless PUBLIC_URL value if we are in dev mode with yarn start), it works as expected:

And the token request to keycloak occurs finalizing the entire authentication standard flow:

And allowing finally load the study list interface, instead of being stuck at /callback.

I verified that with a minor fix here:

The problem is solved, and now the mentioned if case works as expected for both routerBasename '/':

And routerBasename '/viewer':

This fix is for me an acceptable solution for those cases when authentication OIDC standard flow and context path is required. If it is ok for the community, I can open a PR with this minor change.

Thanks and regards!

Steps to Reproduce

1. Deploy keycloak and configure a client id for OHIF (I used the quarkus keycloak image from dcm4chee arc project)
2. Configure default.js with the OIDC settings as explained in the description to work with keycloak
3. Edit the routerBasename to provide a context path different than '/' (for instance, '/viewer')
4. Try to access the OHIF interface, it fails both in dev mode (yarn start) and in prod mode (built with PUBLIC_URL env var)

The current behavior

The authentication standard flow does not finished due to the request to /token endpoint never happens, as it never meets this condition

The expected behavior

once the /auth endpoint of keycload redirects to the /callback endpoint, it is expected that this condition resolves to true and the authentication standard flow continues requesting the /token endpoint of keycloak. Finally, once the /token request is done, the application interface must continue to the study list.

OS

Windows, developing with VS Code directly on WSL. The problem occurs both in dev mode, build mode, and from a docker container also (both official image and built image from the Dokerfile in the Viewers source)

Node version

18.17.1, 18.18.2 and 20.9.0

Browser

Chrome 118.0.5993.90

[sedghi]

Thanks for your in depth issue explanation. I trust your fix works against the keycloak. I tried your fix against our QA server in Google Cloud with OIDC (after confirming the bug), it seems reasonable and works in the dev (which was broken before), but I had hard time making the build works. Are you sure that this works with build as well?

Can you try the google config?

I'm following these

• Have your changes
• Change routerBaseName in config/google.js to /viewer
• Build the app with PUBLIC_URL=/viewer/ APP_CONFIG=config/google.js yarn build
• Navigating to platform/app
• Renaming dist to viewer
• Run npx serve .
• Navigate to localhost:3000/viewer
• The login page appears correctly
• After signing in it says below

Any comment on what is happening? maybe you create a PR and we discuss it there

CleanShot.2023-11-22.at.15.43.45.mp4

[sedghi]

We just release the OHIF 3.8, you can find more details here https://ohif.org/release-notes/3p8/
If you still encounter this issue in 3.8, please re-open this.

[sedghi]

We recently added several recipes for implementing authentication with Keycloak in OHIF. You can find them here:

https://docs.ohif.org/deployment/user-account-control