How to fix no_authorization: No authorization header was provided in Supabase

SupabaseBEGINNERHIGHUpdated Dec 29, 2025· 157 views

The Supabase API requires an Authorization header with a JWT token for authenticated requests. This error occurs when requests to protected endpoints, Edge Functions, or Row Level Security policies don't include a valid JWT token in the Authorization header.

Quick fix

Fixes no_authorization: No authorization header was provided

curl -H "Authorization: Bearer YOUR_JWT_TOKEN" https://your-project.supabase.co/rest/v1/your-table
  1. Verify you're passing a Bearer token in the Authorization header
  2. Extract the access token after sign-in
  3. For server-side operations, pass the user's JWT to the server
  4. For Edge Functions, extract the authorization header
supabase — error
curl -H "Authorization: Bearer YOUR_JWT_TOKEN" https://your-project.supabase.co/rest/v1/your-table
no_authorization: No authorization header was provided

What this error means

Supabase enforces JWT authentication to validate user identity and enforce Row Level Security (RLS) policies at the database level. When you make API requests to Supabase—whether to Edge Functions, REST endpoints, or Realtime subscriptions—the service needs a Bearer token in the Authorization header to identify the user. This error specifically means the request was missing the Authorization header entirely or it was empty. This typically happens when: - Developers forget to include the header when making API calls - Session tokens aren't being passed from the client to the server - The client library isn't properly configured with authentication credentials - A per-request client is created without passing the user's JWT

Typical symptoms

  • Edge Functions return 401 Unauthorized errors
  • REST API calls fail with 'no_authorization' error response
  • Row Level Security policies can't be enforced
  • Realtime subscriptions fail to authenticate
  • Client-side data access fails despite being authenticated in the frontend

Common causes

  1. Missing Authorization header in API requests (header not sent at all)
  2. Empty Authorization header (header present but no token value)
  3. Access token not extracted from session after sign-in
  4. Server-side client created without passing the user's JWT
  5. Realtime client missing authentication setup
  6. Service role key not configured for webhook/backend operations

How to fix "no_authorization: No authorization header was provided"

1Verify you're passing a Bearer token in the Authorization header

For any request to Supabase, ensure you're sending the JWT token with the correct header format:

bash
curl -H "Authorization: Bearer YOUR_JWT_TOKEN" https://your-project.supabase.co/rest/v1/your-table

In JavaScript/TypeScript:

typescript
const response = await fetch('https://your-project.supabase.co/rest/v1/your-table', {
  headers: {
    'Authorization': `Bearer ${accessToken}`,
  }
});

The format is critical: Authorization: Bearer <token> (with a space after "Bearer").

2Extract the access token after sign-in

If you're using Supabase Auth, after a successful sign-in, extract the access token and pass it to subsequent requests:

typescript
const { data, error } = await supabase.auth.signInWithPassword({
  email: 'user@example.com',
  password: 'password'
});

if (data.session) {
  const accessToken = data.session.access_token;
  // Use this token in your API calls
}

Then include it in your fetch requests or create a new client with the token in headers.

3For server-side operations, pass the user's JWT to the server

When making requests from your frontend to a server (Node.js, Python, etc.), send the user's JWT in a header. The server can then use this token when creating a Supabase client:

Client-side:

typescript
fetch('/api/protected-route', {
  headers: {
    'Authorization': `Bearer ${session.access_token}`
  }
});

Server-side (Node.js):

typescript
const authHeader = req.headers.get('authorization');
const token = authHeader?.replace('Bearer ', '');

const supabase = createClient(url, anonKey, {
  global: {
    headers: {
      'Authorization': `Bearer ${token}`
    }
  }
});
4For Edge Functions, extract the authorization header

In Supabase Edge Functions, get the JWT from the request's Authorization header:

typescript
import { serve } from "https://deno.land/std@0.168.0/http/server.ts";
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2';

serve(async (req) => {
  const authHeader = req.headers.get('Authorization');

  if (!authHeader) {
    return new Response(
      JSON.stringify({ error: 'no_authorization' }),
      { status: 401 }
    );
  }

  const token = authHeader.replace('Bearer ', '');
  const supabase = createClient(url, anonKey, {
    global: {
      headers: {
        'Authorization': `Bearer ${token}`
      }
    }
  });

  const { data: user } = await supabase.auth.getUser(token);
  // Now RLS policies will be enforced with this user's context

  return new Response(JSON.stringify({ user }), { status: 200 });
});
5For webhooks or external services, use the service role key

If you need to call Supabase from a webhook or external service without user authentication, use the service role key instead:

bash
curl -H "Authorization: Bearer YOUR_SERVICE_ROLE_KEY" \
     -H "apikey: YOUR_SERVICE_ROLE_KEY" \
     https://your-project.supabase.co/functions/v1/your-function

This bypasses authentication but should only be used for internal or trusted operations. Never expose the service role key in client-side code.

6Verify token hasn't expired

Check if your JWT token has expired. Access tokens typically expire after a set period (default 1 hour in Supabase). If expired, refresh it:

typescript
if (session) {
  const hasExpired = new Date(session.expires_at * 1000) < new Date();
  if (hasExpired) {
    const { data, error } = await supabase.auth.refreshSession();
    // Use the new access token
  }
}

Advanced notes

JWT tokens are essential to Supabase's security model because they carry user identity claims that Row Level Security policies use to determine data access. When RLS is enabled on a table (which is required for public schema exposure), ALL requests must include valid authentication context.

For multi-tenant applications, ensure each request carries the correct user's JWT. This prevents users from accessing other users' data even if they know the table name.

If you're building a server-side application that needs system-wide access, use the service role key in a protected backend—never expose it to clients. The anon key is for client-side use and respects RLS policies.

Frequently asked questions

What does "no_authorization: No authorization header was provided" mean?
Supabase enforces JWT authentication to validate user identity and enforce Row Level Security (RLS) policies at the database level. When you make API requests to Supabase—whether to Edge Functions, REST endpoints, or Realtime subscriptions—the service needs a Bearer token in the Authorization header to identify the user. This error specifically means the request was missing the Authorization header entirely or it was empty.
How do I fix "no_authorization: No authorization header was provided"?
The Supabase API requires an Authorization header with a JWT token for authenticated requests. This error occurs when requests to protected endpoints, Edge Functions, or Row Level Security policies don't include a valid JWT token in the Authorization header.
What causes "no_authorization: No authorization header was provided"?
Missing Authorization header in API requests (header not sent at all) Empty Authorization header (header present but no token value) Access token not extracted from session after sign-in
Is the "no_authorization: No authorization header was provided" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading