Clerk/NextJS interstitial expired tokens

[KylerD]

• Review the documentation: https://clerk.com/docs
• Search for existing issues: https://github.com/clerkinc/javascript/issues
• Go through package changelog files.
• Provide the Frontend API key from your application dashboard.

Package + Version

• @clerk/nextjs

Dependencies + versions

 "dependencies": {
    "@clerk/nextjs": "^4.20.0",
    "next": "^13.4.1",
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@types/node": "^17.0.12",
    "@types/react": "^18.0.22",
    "@types/react-dom": "^18.0.7",
  }

Description

Hey folks,

My application has a typeahead component which makes requests to an internal /api/places endpoint as the user types.

 async function enterSearch(query: string) {
     await fetch(`/api/places?searchInput=${query}`, {
        method: 'GET'
      });
    }
  }

This is just a simplified example, the actual component has debounce controls etc to manage requests, none the less there is a common issue caused by clerk where by my middleware throws the following error:

 -- Options debug, {
"debug": true,
 "beforeAuth": false,
"afterAuth": false
}
-- authenticateRequest state is interstitial in an API route, {
"status": "interstitial",
"reason": "token-expired",
"message": "JWT is expired. etc...",
"frontendApi": "<frontend-api>",
"publishableKey": "<key>",
"isSatellite": false,
 "domain": "",
"proxyUrl": "",
"signInUrl": "/sign-in",
"isSignedIn": false,
"isInterstitial": true,
"isUnknown": false
}

It seems that the application only recovers from this state when I prevent typing again for about 30-60 seconds. I've tried marking the api endpoint as a public route, ignored route etc but the only way to prevent this error thus far has been to remove the middleware. I was unable to find any documentation about this state or behaviour so would appreciate a steer.

Many thanks,
KD

[Andriy-Kulak]

We are getting similar error. Next.js. Sometimes we get the "Auth token Expired", and then 30 seconds later it works again. The issue is that the KWT token between the 401 and 200 requests is the same, so there is nothing I can do on my end. Please assist

[Andriy-Kulak]

I was able to recreate the issue. @clerk/nextjs^14.19.1

Wait for client to try to refresh the token. once that request is made. the subsequent request will return a 401 "Authorization token expired". If you then try again, the next request will succeed. This is a terribly experience for the user as they will typically not try to retry.

Below is an example:

[Andriy-Kulak]

just tried updating to 4.23.1 and get the same error. @SokratisVidros any ideas on how to resolve this?

[Andriy-Kulak]

Ok i figured out the problem. not related to clerk directly although people should be aware of. Clerk refreshes JWT token every 1 minute. This means that we should be fetching the token at the time of the request every time.

If you fetch the token once when the page was first loaded & try to use only that token for subsequent actions, they will not work after that token expires in 1 minute.

[KylerD]

Just a heads up my endpoint calls 'const { userId } = getAuth(request);' on every request and I still get this error.

[dimkl]

Hello @KylerD
There are 2 different approaches to use the Clerk auth:

• Cookie
• Authorization header
  Based on your example (if fetch refers to the global fetch and not a wrapper) you are using the Cookie approach since you don't provide an authorization header.
  Using the Cookie approach, means you don't need to use getToken() on every request since we have a mechanism to handle the cookie refresh.

I've tried marking the api endpoint as a public route, ignored route etc but the only way to prevent this error thus far has been to remove the middleware.
Marking the endpoint as ignored route the middleware should not run. Could you retry this and if the middleware is trigger provide me with a middleware.ts example to investigate it further?
Marking the endpoint as public will not resolve your issue since the check for the cookies will run.

Could you try to disable the debounce controls etc to manage requests from the component and check if the current implementation works ?
If it's still not working, could you provide me with a sample repository or invite me to the repository to take a better look and try to reproduce the issue?

(if the above does not work) You could temporarily try for the following approach:

• Use the Authorization header approach where token = await getToken()

 async function enterSearch(query: string, token: string) {
     await fetch(`/api/places?searchInput=${query}`, {
        method: 'GET',
        headers: { Authorization: `Bearer ${token}` }
      });
    }
  }

[dimkl]

@Andriy-Kulak did you use the same-origin (without Authorization header) or the cross-origin approach (with Authorization header) ?
https://clerk.com/docs/request-authentication/overview

[KylerD]

Hey @dimkl - my api route uses the basic approach specified here: https://clerk.com/docs/nextjs/api-routes?utm_source=www.google.com&utm_medium=referral&utm_campaign=none

I just return a 401 if userId is null. If there's a better approach to protecting the route I am happy to change it, I just wasn't 100% on what route protection is provided out of the box.

I can provide further details later today once I'm back at my computer 👍

[dimkl]

did you use the same-origin (without Authorization header) or the cross-origin approach (with Authorization header)?
@KylerD i was referring to the way you make the fetch API call.

Did you try the Use the Authorization header approach I suggested?

[KylerD]

Sorry for the delay @dimkl - it's currently a same origin request without auth header i.e.

 async function enterSearch(query: string) {
      const resp = await fetch(`/api/places?searchInput=${query}`, {
        method: 'GET'
      });
  }

The corresponding route.ts:

import { getAuth } from "@clerk/nextjs/server";
import { NextRequest, NextResponse } from 'next/server'

export async function GET(request: NextRequest) {
  const { userId } = getAuth(request);

  if (!userId) {
    return NextResponse.json({ error: HTTPMessage.Unauthorised }, { status: HTTPCode.Unauthorised });
  }
 ...
}

I setup a new demonstration repo to try and reproduce the issue in an isolated context, although it seems to be working correctly so I am a bit stumped.. I will need to try with my project repository again this evening to see if I can still reproduce, will update in a few hours and try the explicit auth header too

[dimkl]

@KylerD let me know how it goes :)

[KylerD]

@dimk got it !

TLDR: System clock issue

This one is on me, but posting the details here as it might help others. I went to start my application this evening and noticed I was getting an infinite redirect loop on sign-in, which I hadn't seen yet. I decided to do an upgrade from Clerk 4.20 -> 4.23.1 and change all my import { getAuth } from "@clerk/nextjs/server"; imports to import { auth } from "@clerk/nextjs" as shown in the getting started docs as I was getting desperate 😅

I set the 'debug' flag in the middleware.ts to help figure out what the issue was:

 -- Options debug, {
nuj-frontend:dev:   "debug": true,
nuj-frontend:dev:   "beforeAuth": false,
nuj-frontend:dev: - error ..\..\node_modules\.pnpm\@clerk+nextjs@4.23.1_next@13.4.1_react-dom@18.2.0_react@18.2.0\node_modules\@clerk\nextjs\dist\esm\server\authMiddleware.js (163:0) @ assertInfiniteRedirectionLoop
nuj-frontend:dev: - error Clerk: Infinite redirect loop detected. That usually means that we were not able to determine the auth state for this request. A list of common causes and solutions follows.
nuj-frontend:dev:   "afterAuth": false
nuj-frontend:dev: }

Server Error
Error: Clerk: Infinite redirect loop detected. That usually means that we were not able to determine the auth state for this request. A list of common causes and solutions follows.

Reason 1:
Your server's system clock is inaccurate. Clerk will continuously try to issue new tokens, as the existing ones will be treated as "expired" due to clock skew.
How to resolve:
-> Make sure your system's clock is set to the correct time (e.g. turn off and on automatic time synchronization).

Reason 2:
Your Clerk instance keys are incorrect, or you recently changed keys (Publishable Key, Secret Key).
How to resolve:
-> Make sure you're using the correct keys from the Clerk Dashboard. If you changed keys recently, make sure to clear your browser application data and cookies.

Reason 3:
A bug that may have already been fixed in the latest version of Clerk NextJS package.
How to resolve:
-> Make sure you are using the latest version of '@clerk/nextjs' and 'next'.

This error happened while generating the page. Any console logs will be displayed in the terminal window.

Sure enough, my system clock was slightly off and hadn't been synced in a while!

[dimkl]

@KylerD nice!