bug: client access token for auth admin API is not properly refreshed

[spygi]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

The Supabase client after some time (I believe when access token gets refreshed) stops working for Auth admin calls. Once it stops working no subsequent request is successful anymore and the only remedy I found is to restart the server so that the initialization starts again.

To Reproduce

supabase = None

def a_function():
    global supabase
    if not supabase:
        supabase = create_client(SUPA_URL, SUPA_KEY, # using the service role here
          options=ClientOptions(
                postgrest_client_timeout=10, # seconds?
                storage_client_timeout=10,
          )) 
      
    users = supabase.auth.admin.list_users(page=page_num). -> 403 User not allowed

At the API Gateway logs:

Expected behavior

Initial requests succeed. After some time they fail. Since the key is the service_role, requests should go through.

Screenshots

Debugging through the Supabase code, I noticed that when the request fail with 403 ('user not allowed) the apiKey differs from the Authorization header

This prompted me to change manually (in the debugger) the Authorization header with the apiKey. Request went through which proves that the apiKey is not the issue.

What is more in initial requests the Bearer is the same as the apiKey.

Could it be that the access token refresh is not working correctly?

System information

• OS: macOS
• Browser: server-side, FastAPI 0.115.12
• Version of supabase-py: 2.15.2, sync client (async client does not even work for supabase.auth.admin.list_users)
• Version of Python: 3.12

Additional context

In general, would be great to add in the docs the proper way to initiate the supabase client for reuse in a server environment. People are asking also in #697 for such instructions.

Note the same pattern with global seems to work ok for non-admin auth calls e.g. supabase.auth.sign_in_anonymously

[spygi]

Related thread https://github.com/orgs/supabase/discussions/33811 (uses global mechanism as well)

[silentworks]

Auth admin calls use the service_role key so there is no refreshing of any token happening there. Are you using multiple supabase clients in the same project?

The thread you linked to is also not related as it's asking about a different issue.

[spygi]

Auth admin calls use the service_role key so there is no refreshing of any token happening there

Hm.. after the postgrest_client_timeout I can see the Bearer has a different value than the service role (although initially it's the api key).

Are you using multiple supabase clients in the same project?

Yes I am. For now each module in my code (a FastAPI server) has their own supabase client which is initialised with a singleton-like pattern (for re-use at least on the module-level and to not re-initialize for every function call).

supabase = None
def foo():
  global supabase
  if not supabase:
     supabase = create_client

This seems to work ok for non auth.admin calls but haven't load tested it really so I might not have hit the limit there.

Ideally I want something process-scoped (not module-scoped). The manual way would be I guess with a initialization module that is called from everywhere and provides a single client across the application, if that's the recommended approach?

I am aware of the different connection options but I understand they apply when using the connection string, not a client SDK?

I suspect the module-global pattern might be the issue maybe because the reference to the client is not garbage collected but the client it not "active" (but this doesn't explain the different Bearer)? That's why I linked this thread as OP also asks about the recommended pattern for Supa with FastAPI.

What do you recommend? Is there a pattern like returning a single client with a specified pool of (httpx?) connections?

[spygi]

Any input here?

Should we use a contextvar so that there is a single client for each request?