Sign in with Authentik button does nothing — race condition in login redirect

[jeremyzilar]

Describe the bug

Clicking the "Sign in with Authentik" button on the login page does nothing. No redirect to Authentik occurs and no errors appear in the browser console. The issue is intermittent — it reliably works when Chrome DevTools is open, but fails when DevTools is closed.

To Reproduce

1. Open the app in Chrome (without DevTools open)
2. Navigate to the login page
3. Click "Sign in with Authentik"
4. Nothing happens — the user remains on the login page

Expected behavior

Clicking the button should redirect the browser to the Authentik authorization URL to begin the OAuth/PKCE login flow.

Additional context

• Clearing cookies, local storage, and using incognito mode does not resolve the issue.
• The login flow works reliably when Chrome DevTools is open.

Root cause

The login method in src/providers/authentik-provider.ts calls window.location.assign(authUrl) to redirect to Authentik, then returns { success: true }. When Refine receives that successful result, it immediately triggers internal post-login navigation — routing to the default page, running the check() auth guard (which finds no token), and redirecting back to /login via React Router. This internal navigation cycle preempts the browser's pending window.location.assign() redirect, effectively canceling it.

When Chrome DevTools is open, the added instrumentation overhead slows JavaScript execution just enough for window.location.assign() to win the race and navigate to Authentik before Refine's routing can interfere.

Proposed fix

In src/providers/authentik-provider.ts, replace return { success: true } after the window.location.assign() call with return new Promise(() => {}). This returns a never-resolving promise, preventing Refine from processing any post-login navigation while the browser redirects. Additionally, wrap the PKCE generation in a try/catch so that failures in crypto.subtle.digest surface a user-facing error instead of silently swallowing the exception.

[TylerAdamMartinez]

I agree with the root-cause analysis (Refine reacts to { success: true } by continuing its normal “post-login” flow, which can trigger navigation/check and effectively race/cancel the pending window.location.assign() redirect). This strongly suggests a timing/race.

That said, the proposed fix of return new Promise(() => {}) is likely the wrong lever:

• It intentionally leaves the auth action unresolved forever, which can hang UI state / loading indicators and makes debugging harder.
• It’s also a bit fragile—if anything prevents the browser navigation (popup blockers, blocked redirect, CSP), the app can end up stuck.

Refine has a more idiomatic way to handle this: AuthActionResponse supports redirectTo?: string. Instead of calling window.location.assign() and returning success, we can return a redirect instruction and let Refine own the navigation.

refine.dev core docs on the auth-provider