You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Quarkus OIDC already has OidcRequestFilter which can be used to intercept direct requests to various OIDC endpoints.
But redirects to OIDC authorization or logout endpoints, or local redirects to the error or session expired pages can not be intercepted.
In the latter case, when, for example, a user whose session has expired, is redirected to the session expired page, it is impossible to generate such a page correctly when multiple OIDC tenants are involved, for example, given Keycloak and Auth0, the session expired page handler does not know where to link the user to, for this user to initiate a provider specific re-authentication.
The custom redirect filter can help by creating a secure cookie capturing the tenant info and the session expired page handler can use it to create a correct re-authentication link.
Or users may want to intercept redirects to the OIDC authorization endpoint itself, for example, to add some extra redirect parameters dynamically or set extra headers etc, as tried in #40547.
Note, currently, we have AuthenticationRedirectException but I'm not sure we should look at mapping such exceptions at the JAX-RS level as a standard recommended solution, as the way to manage such redirects. It won't work anyway for the multi-tenant OIDC setup since AuthenticationRedirectException can not be made aware of the OIDC tenant config.
Description
Quarkus OIDC already has
OidcRequestFilter
which can be used to intercept direct requests to various OIDC endpoints.But redirects to OIDC authorization or logout endpoints, or local redirects to the error or session expired pages can not be intercepted.
In the latter case, when, for example, a user whose session has expired, is redirected to the session expired page, it is impossible to generate such a page correctly when multiple OIDC tenants are involved, for example, given Keycloak and Auth0, the session expired page handler does not know where to link the user to, for this user to initiate a provider specific re-authentication.
The custom redirect filter can help by creating a secure cookie capturing the tenant info and the session expired page handler can use it to create a correct re-authentication link.
Or users may want to intercept redirects to the OIDC authorization endpoint itself, for example, to add some extra redirect parameters dynamically or set extra headers etc, as tried in #40547.
Note, currently, we have
AuthenticationRedirectException
but I'm not sure we should look at mapping such exceptions at the JAX-RS level as a standard recommended solution, as the way to manage such redirects. It won't work anyway for the multi-tenant OIDC setup sinceAuthenticationRedirectException
can not be made aware of the OIDC tenant config.CC @pedroigor @gastaldi @calvernaz
Implementation ideas
Add
OidcRedirectFilter
, use@TenantFeature
to bind it to specific tenants if neededThe text was updated successfully, but these errors were encountered: