Deeplinking with Entra ID auth fails due to inability to configure wildcard RedirectURIs

[slknijnenburg]

Description

Registry
Version: 3.0.9 and latest-snapshot as of 2025-JUN-25.
Persistence type: n/a

This is a follow-up of #6329 (comment): on the latest-snapshot version Entra ID authentication and authorization are working again, which is great 🎉 However, EntraID requires the use of explicitly configured redirect URIs and does not allow using wildcard in the UIs (see docs). This currently prevents deeplinking into any page of Apicurio UI that is not explicitly allowlisted as a redirect URI.

The solution for this seems to be using a query parameter with the path to which the enduser should be redirected after successful login. This only works for EntraID business/school accounts, not for personal Microsoft accounts, but I reckon that that might be an acceptable trade-off.

Environment

Tested in a K8s setup with apicurio-ui and apicurio-registry running in 2 separate pods. Everything else works as expected, only the deeplinking does not.

Steps to Reproduce

The docker-compose setup as described in #6329 (comment) should be sufficient to replicate the issue.

Expected vs Actual Behaviour

Expected behavior: after authenticating, the user is redirected to the page they initially requested.
Actual behavior: except for explicitly allowlisted URLS, the user is faced with an Azure "Sign in" error page with:

AADSTS50011: The redirect URI 'https://<redacted>.com/settings' specified in the request does not match the redirect URIs configured for the application '<redacted>'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this. 

[EricWittmann]

OK so this is unfortunate. We obviously don't want to switch from path based routing to query param based routing for the UI itself. So we have two possible solutions:

1. Add an option to disable deep linking for OIDC auth
2. Configure the OIDC redirect URL with a custom query param containing the desired route

Obviously (1) is easy to implement and can be done immediately.

Option (2) is not that hard but annoying to implement for the value it provides. I wonder if there might be a volunteer out there for this, if it's important.