HTTP: 400 on authenticate with missing refresh-token when devMode=false (refresh-token not persisted correctly)

[Oyveloper]

We recently set up auth-kit-react with TanStack (i.e. fully client side), following the instructions on https://workos.com/docs/user-management/client-only/2-add-authkit-to-your-app

Locally, all is fine as devMode is True, and refresh-token is stored in local storage.
When deploying the site however, we get a 400 error whenever auth-kit tries to reauthenticate, as it does not pass the refresh-token.

However, setting devMode true works well also in production.

Anyone got an idea why the prod setup does not work in our case?

Our test-setup to debug:

import { Outlet, createRootRoute, useNavigate } from '@tanstack/react-router';
import { AuthKitProvider } from '@workos-inc/authkit-react';
import { useEffect, useState } from 'react';
import { useLocation } from '@tanstack/react-router';
import { useAuth } from '@workos-inc/authkit-react';


function ProviderWrapper() {
  const [redirect, setRedirect] = useState<{ returnTo: string; search: any } | null>(null);
  const navigate = useNavigate();

  useEffect(() => {
    if (redirect) {
      navigate({ to: redirect.returnTo, search: redirect.search });
    }
  }, [redirect]);

  return (
    <>
      <AuthKitProvider
        clientId={getEnvVar('WORKOS_CLIENT_ID')}
        redirectUri={getWorkosRedirectURI()}
        onRedirectCallback={({ state }) => {
          if (state?.returnTo) {
            setRedirect({ returnTo: state.returnTo, search: state.search });
          }
        }}
      >
        <ShortcutProvider>
          <RecoilRoot>
            <Root />
          </RecoilRoot>
        </ShortcutProvider>
      </AuthKitProvider>
    </>
  );
}

export default function useUser() {
  const { user, getAccessToken, isLoading, signIn } = useAuth();
  const location = useLocation();

  useEffect(() => {
    if (!isLoading && !user) {
      signIn({ state: { returnTo: location.pathname + '/', search: location.search } });
    }
  }, [isLoading, user]);


  return { user, isLoading, getAccessToken };
}


function Root() {
  const { user, isLoading, getAccessToken } = useUser();
  if (isLoading || !user) return <FullScreenSpinner />;

  return <>Hello world</>;

}

[cmatheson]

@Oyveloper I'll push up a fix for the instructions you referenced. You must pass apiHostname to AuthKitProvider in order for the cookie to get set properly for production mode (see the example in the README).

[Oyveloper]

ok, so apiHostname should be the domain for our backend api?. The way we read the README this should be the auth domain, which in our case is workos:

apiHostname: Defaults to api.workos.com. This should be set to your custom Authentication API domain in production.

[cmatheson]

@Oyveloper it should be your auth domain, but you need a custom auth domain so that the session cookie can be set properly. If you don't have a custom domain, just keep devMode={true} on your <AuthKitProvider>

[Oyveloper]

Hmm ok, perhaps the devMode field should be named differently, if it is a viable strategy to run in production with devMode={true}?
Or should we simply put the default authKit Domain that we can see in the workos dashboard (i.e. random-string.authkit.app)?

[cmatheson]

@Oyveloper we don't recommend running in devMode in production. Having the refresh token in local storage is less secure than the httponly cookie (this might be an acceptable amount of risk for your app).

You won't be able to use the authkit.app domain (it's not an API endpoint, and also 3rd party cookie blocking will prevent the cookie from being set properly).

Our recommendation for SPAs is to register a custom domain with WorkOS and use that as your apiHostname.

[Oyveloper]

So you say we need to pay the $99/month for custom domain in order to use the more secure option?

[Dhruv-Mehndhiratta-Centml]

So you say we need to pay the $99/month for custom domain in order to use the more secure option?

even i have setup the apiHostname and paid the amount i am not able to see authenticate api call on the reload of the app like how it does it on localhost or devmode=true, and its causing my api to fail with 401 which is valid since its not authorized and token is expired.

I am using loader functions and the only way for me to grab the token is cookies and i was expecting onRefresh callback would trigger and update my cookies but onRefresh only works or in simple words it makes the authenticate api call only in dev mode which is bit weird. Is there anything which I am missing?
CC: @nicknisi

[mags-sully]

@cmatheson when using dev credentials and our custom auth domain I am also seeing the 400 on authenticate with no refresh token. I am hesitant to launch this in production unless you know that even with api hostname this will fail unless we use the production credentials or something to that effect

[DarkmatterVale]

Is:

@Oyveloper it should be your auth domain, but you need a custom auth domain so that the session cookie can be set properly. If you don't have a custom domain, just keep devMode={true} on your <AuthKitProvider>

Anywhere in the documentation? I struggled with this as well, it didn't come across clearly when I was onboarding.

[zacharyhansen]

I am also hitting this same issue, the getAccessToken method from @workos-inc/authkit-react is broken and unable to correctly pull the refresh token in a nextjs app.

I have tried every combo of apiHostname="api.workos.com" & apiHostname="auth.workos.com" / devMode={true} & devMode={false} but still encounter the error

{
    "error": "invalid_request",
    "error_description": "Missing refresh token."
}

Any update on this?

[joZephhh]

Facing the same issue, here!

@cmatheson can you confirm here, or provide alternative/guidance, that in a client-side only setup of AuthKit, we must have a custom auth domain (99$/month) in order to be able to refresh token through getAccessToken ?

[jly-x]

What I see from the docs as of today:

If you have not set up a custom authentication domain in WorkOS, set devMode={true} on . This will keep the refresh token in local storage instead of a secure, HTTP-only cookie.

So I think yes:

1. AuthKit is free
2. If you're on the free plan, you must store the refresh token in local storage, which has security vulnerabilities, and must set devMode = true to use refresh tokens at all.
3. If you are on the $99/mo plan, you can store them in the secure HTTP-only cookies.

[mitrushchienkova]

I confirm what @jly-x stated.

After checking with WorkOS support and then adding custom domains, the behavior is the following:

• Local storage works in all environments on the free plan, and it also works in the Staging environment once a custom domain is added.
• In Production, HTTP-only cookies are used when a custom domain is enabled.

[jbellmont]

Hmm this should definitely be more explicit in their docs.