unauthorized
API Reference for the unauthorized function.
The unauthorized function throws an error that renders a Next.js 401 page. It's useful for handling authentication errors, when a request is not signed in. You can customize the UI using the unauthorized.js file.
Invoking unauthorized() throws a NEXT_HTTP_ERROR_FALLBACK;401 error and terminates rendering of the route segment where it was thrown. Next.js also injects a <meta name="robots" content="noindex" /> tag so the page is not indexed. Because it works by throwing, call it in the render path: a component, or a function a component awaits. A call left in an un-awaited promise throws where nothing catches it, and no unauthorized UI renders.
To start using unauthorized, enable the experimental authInterrupts configuration option in your next.config.js file:
unauthorized can be invoked in Server Components, Server Functions, and Route Handlers.
Good to know
- The
unauthorizedfunction cannot be called in the root layout. - You do not need to write
return unauthorized(). It throws (its TypeScriptneverreturn type), so execution stops. Atry/catcharound the call suppresses the interrupt and no unauthorized UI renders. Useunstable_rethrowto let it through. - An
unauthorized()left in an un-awaited promise throws where nothing catches it, so no unauthorized UI renders. In development the server logs⨯ unhandledRejection: NEXT_HTTP_ERROR_FALLBACK;401. Alwaysawaitthe function that may call it.
Examples
Calling unauthorized() after streaming has started
To keep the page's shell and loading UI visible while the session is verified, put the auth check in the Data Access Layer function that loads the data, and render it in a component wrapped in <Suspense>. The check runs inside the boundary, so the shell streams while the session resolves:
When the request isn't signed in, getAccount calls unauthorized(), which throws. Because this happens during rendering, the exception propagates to the nearest unauthorized boundary, which renders in place of the streamed-in content, even though the page shell has already been sent.
Add an unauthorized.tsx alongside the route to define that UI:
The trade-off is the HTTP status code. Because the check runs inside the <Suspense> boundary, the response has already begun streaming as a 200, and the status can't change once streaming has started. This is usually fine for a page, where the user sees the unauthorized UI regardless. To return a real 401 status, the check has to run before the response streams. With Cache Components, every dynamic route streams a static shell first, so run that check in proxy instead. See Status codes.
Displaying login UI to unauthenticated users
You can use unauthorized function to display the unauthorized.js file with a login UI.
Mutations with Server Actions
You can invoke unauthorized in Server Actions to ensure only authenticated users can perform specific mutations.
Fetching data with Route Handlers
You can use unauthorized in Route Handlers to ensure only authenticated users can access the endpoint.
Version History
| Version | Changes |
|---|---|
v15.1.0 | unauthorized introduced. |