Supabase Auth providers show Enabled in Dashboard but runtime says disabled

[titutaweh-cmd]

Hello Supabase team/community,

I need help diagnosing a Supabase Auth issue with my production project.

I have already submitted a support request for this issue and am posting here to get community guidance while I wait for the support response.

Problem:

The Supabase Dashboard shows both Email and Google authentication providers as ENABLED, but the production Auth runtime behaves as though both providers are disabled.

Evidence:

Email/password sign-in
POST /auth/v1/token

HTTP 422

Error:
email_provider_disabled

Message:
"Email logins are disabled."

Password recovery
POST /auth/v1/recover

HTTP 400

Error:
email_provider_disabled

Message:
"Email logins are disabled."

Google OAuth
GET /auth/v1/authorize?provider=google

HTTP 400

Response:
"Unsupported provider: provider is not enabled"

However, in Supabase Dashboard:

Authentication → Sign In / Providers:

Email: Enabled
Google: Enabled
The detailed Email provider settings also show:
"Enable email provider" = ON.

The application is connected to the expected Supabase project.

A read-only investigation also found:

Email authentication fails at the provider-availability stage, before password validation or user lookup.
Google OAuth fails at provider availability.
No Auth Hook is involved.
This is not an RLS/database policy failure.
The application code does not contain these backend error messages.
Production and preview are connected to the expected Supabase project.
The Auth log stream subsequently showed no Auth events for fresh sign-in/password-reset attempts, while other project logs were still active.
This appears to be a discrepancy between the provider configuration displayed by the Supabase Dashboard and the configuration being used by the Auth runtime.

Could someone please advise what could cause the Dashboard to show Email and Google as enabled while the Auth runtime reports both providers as disabled?

I have not changed Auth configuration, database schema, RLS policies, secrets, or application code while investigating this issue.

I will not post API keys, passwords, access tokens, database credentials, or other secrets here.

Thank you.

[alpsten]

This looks like it could be desync between the saved Dashboard config and what the Auth (GoTrue) runtime actually has loaded, not something wrong in your app or database.

A few things point that way because...

• email_provider_disabled and "Unsupported provider: provider is not enabled" are both errors GoTrue throws when it reads Enabled: false for that provider internally. The Dashboard toggle and the live runtime config are two different reads, and right now they disagree.

• The fact that both an email-based flow and an OAuth flow fail at the same "provider availability" gate, before any user lookup or logging, points to the Auth service itself booting/refreshing with a stale or default config rather than two unrelated provider bugs.

• No entries in the Auth log stream for fresh attempts is consistent with this. The request is being rejected (what is seems like) before it reaches the stage that gets logged, meaning the check is happening very early in GoTrue's request handling, off whatever config it currently has in memory.

• This is very likely connected to the "Unhealthy" / disk-full WAL crash issue I posted about separately (project wmiujmxszbbtbnhfgcee, disk filled up via pg_wal, project stuck refusing connections). If the project went through an unhealthy recovery cycle, that's a plausible trigger for the Auth service coming back up on a fresh/default config instead of the one saved in the Dashboard, while the Dashboard UI itself just kept displaying the last-known saved state. I'm flagging this explicitly since support may be treating these as two separate tickets when they're likely the same underlying incident.

A couple of quick, low-risk things to rule out first while waiting on support:

1. In Authentication -> Providers, toggle Email off, Save, then back on, Save again (same for Google). This sometimes forces a fresh config write/sync to the Auth service rather than the UI just reflecting a value that never actually persisted correctly.
2. Double check the project ref and anon/publishable key your app is using match the project you're looking at in the Dashboard, worth ruling out a second/duplicate project or a stale cached key.
3. Check status.supabase.com for any incident in your project's region around when this started.

For support, since this is a runtime/config sync issue rather than anything client-visible, it needs someone with backend access to check what config the Auth container actually has loaded for this project vs. what's stored. Worth including in the ticket:

• Exact timestamps of the 422/400 responses above
• The project ref
• A pointer to the disk-full/unhealthy incident on the same project, since they're almost certainly related

[titutaweh-cmd]

Confirmed after project restart

I restarted the project from Supabase Dashboard, and the problem persists.

After the restart, Supabase Dashboard still shows:
Authentication → Sign In / Providers → Email: Enabled

I then tested a fresh production login from:
https://vendopad-nigeria-connect.lovable.app

Chrome Network shows the request reaching:
/auth/v1/token?grant_type=password

The response is HTTP 422 with:

{"code":"email_provider_disabled","message":"Email logins are disabled"}

So the live GoTrue/Auth service is still reporting Email as disabled even though the Dashboard shows Email Enabled.

I have also verified that the project's Postgres database is intact and contains existing VendoPad data. No destructive database changes were made.

Please investigate the managed Auth/GoTrue configuration for project ref:
mbxbqvohiscdxzfizhok

Specifically, please check why the live Auth runtime has email/password disabled while the Dashboard configuration shows Email enabled.

[titutaweh-cmd]

Hi Supabase Support, I wanted to give you a clearer update after doing a few more checks on my side. I initially thought the problem might be related to Lovable Cloud or the project being connected to the wrong Supabase backend, so I went through the configuration carefully. I can now confirm that the published VendoPad app is connected to the correct Supabase project: *Project ref:* mbxbqvohiscdxzfizhok I also confirmed that Lovable Cloud is not pointing the app to another backend. The production build, project configuration, and Supabase client are all using the same project. I then checked the database directly using read-only SQL. The VendoPad database is still there and contains real data: - 50 public tables - 113 public functions - 13 merchants - 23 products - 56 sales - 21 customers - 9 expenses - 78 sale items - 25 restock history records So the database itself has not disappeared or been replaced. The problem that remains is specifically with Supabase Auth. The Dashboard shows: *Email provider: Enabled* But the live Auth runtime reports: *email: false* I also tried the provider isolation test suggested in the GitHub discussion. I disabled Google and left Email enabled, but email login still failed. I then tried the suggested Email configuration refresh: 1. Disabled Email and saved. 2. Enabled Email again and saved. 3. Checked the live Auth runtime afterward. The runtime still reported: email: false So the Dashboard change is being saved, but it doesn't appear to be reaching the running Auth service. Fresh login attempts from the production VendoPad app returned: *HTTP 422 — email_provider_disabled* The two request IDs are: 01a0d048-d0a5-7a74-bc8f-377c715aa37f 01a0d049-e8f1-759d-9866-caa8f3dfd250 The Auth service rejects the request at the provider availability stage, before checking the user's password. At this point, I believe the remaining issue is the difference between the Email provider setting shown in the Dashboard and the Email provider configuration actually loaded by the live GoTrue/Auth service. Could you please check the backend configuration for this project and see why the Email provider is still being loaded as disabled even though the Dashboard shows it as enabled? I have not created another project, changed the database, modified RLS, or made any destructive changes. I also have not used Lovable's automated "Try to fix" option because I don't want to accidentally change the backend configuration while this is being investigated. Thank you for your help. I've spent a lot of time building VendoPad and would really appreciate help getting the existing project back to normal rather than having to recreate anything. Best regards, Titus Nentawe VendoPad

…

On Thu, Sep 24, 2026 at 8:35 AM emil alpsten ***@***.***> wrote: This looks like it could be desync between the saved Dashboard config and what the Auth (GoTrue) runtime actually has loaded, not something wrong in your app or database. A few things point that way because... - email_provider_disabled and "*Unsupported provider: provider is not enabled*" are both errors GoTrue throws when it reads Enabled: false for that provider internally. The Dashboard toggle and the live runtime config are two different reads, and right now they disagree. - The fact that both an email-based flow and an OAuth flow fail at the same "*provider availability*" gate, before any user lookup or logging, points to the Auth service itself booting/refreshing with a stale or default config rather than two unrelated provider bugs. - No entries in the Auth log stream for fresh attempts is consistent with this. The request is being rejected (what is seems like) before it reaches the stage that gets logged, meaning the check is happening very early in GoTrue's request handling, off whatever config it currently has in memory. - This is very likely connected to the "*Unhealthy*" / disk-full WAL crash issue I posted about separately (project *wmiujmxszbbtbnhfgcee*, disk filled up via pg_wal, project stuck refusing connections). If the project went through an unhealthy recovery cycle, that's a plausible trigger for the Auth service coming back up on a fresh/default config instead of the one saved in the Dashboard, while the Dashboard UI itself just kept displaying the last-known saved state. I'm flagging this explicitly since support may be treating these as two separate tickets when they're likely the same underlying incident. A couple of quick, low-risk things to rule out first while waiting on support: 1. In Authentication -> Providers, toggle Email off, Save, then back on, Save again (same for Google). This sometimes forces a fresh config write/sync to the Auth service rather than the UI just reflecting a value that never actually persisted correctly. 2. Double check the project ref and anon/publishable key your app is using match the project you're looking at in the Dashboard, worth ruling out a second/duplicate project or a stale cached key. 3. Check status.supabase.com for any incident in your project's region around when this started. For support, since this is a runtime/config sync issue rather than anything client-visible, it needs someone with backend access to check what config the Auth container actually has loaded for this project vs. what's stored. Worth including in the ticket: - Exact timestamps of the 422/400 responses above - The project ref - A pointer to the disk-full/unhealthy incident on the same project, since they're almost certainly related — Reply to this email directly, view it on GitHub <#50819?email_source=notifications&email_token=CJQV6ZXFYGPBMDDEDBGM4X35QTFELA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVG43TINRWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18577466>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CJQV6ZXP3KOWFMWITYHOK3D5QTFELAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBYG4ZTOOJUUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CJQV6ZT7YQ6USAKCQ3MZ2EL5QTFELA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVG43TINRWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CJQV6ZSKF6YOYWRUS62EYT35QTFELA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVG43TINRWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[titutaweh-cmd]

*Update on SU-483327 — confirmed after project restart* I restarted the project from Supabase Dashboard, and the problem persists. After the restart, Supabase Dashboard still shows: *Authentication → Sign In / Providers → Email: Enabled* I then tested a fresh production login from: https://vendopad-nigeria-connect.lovable.app Chrome Network shows the request reaching: /auth/v1/token?grant_type=password The response is HTTP *422* with: {"code":"email_provider_disabled","message":"Email logins are disabled"} So the live GoTrue/Auth service is still reporting Email as disabled even though the Dashboard shows Email Enabled. I have also verified that the project's Postgres database is intact and contains existing VendoPad data. No destructive database changes were made. Please investigate the managed Auth/GoTrue configuration for project ref: mbxbqvohiscdxzfizhok Specifically, please check why the live Auth runtime has email/password disabled while the Dashboard configuration shows Email enabled. Titus Nentawe Nigerpet Structures Limited Plot G.32 Ewet Housing Estate Uyo Akwa ibom State Nigeria. Alt email: ***@***.*** Tel: +234 (0) 8037755927 (0) 8023016242

…

On Thu, Sep 24, 2026 at 9:59 AM Titus Nentawe ***@***.***> wrote: Hi Supabase Support, I wanted to give you a clearer update after doing a few more checks on my side. I initially thought the problem might be related to Lovable Cloud or the project being connected to the wrong Supabase backend, so I went through the configuration carefully. I can now confirm that the published VendoPad app is connected to the correct Supabase project: *Project ref:* mbxbqvohiscdxzfizhok I also confirmed that Lovable Cloud is not pointing the app to another backend. The production build, project configuration, and Supabase client are all using the same project. I then checked the database directly using read-only SQL. The VendoPad database is still there and contains real data: - 50 public tables - 113 public functions - 13 merchants - 23 products - 56 sales - 21 customers - 9 expenses - 78 sale items - 25 restock history records So the database itself has not disappeared or been replaced. The problem that remains is specifically with Supabase Auth. The Dashboard shows: *Email provider: Enabled* But the live Auth runtime reports: *email: false* I also tried the provider isolation test suggested in the GitHub discussion. I disabled Google and left Email enabled, but email login still failed. I then tried the suggested Email configuration refresh: 1. Disabled Email and saved. 2. Enabled Email again and saved. 3. Checked the live Auth runtime afterward. The runtime still reported: email: false So the Dashboard change is being saved, but it doesn't appear to be reaching the running Auth service. Fresh login attempts from the production VendoPad app returned: *HTTP 422 — email_provider_disabled* The two request IDs are: 01a0d048-d0a5-7a74-bc8f-377c715aa37f 01a0d049-e8f1-759d-9866-caa8f3dfd250 The Auth service rejects the request at the provider availability stage, before checking the user's password. At this point, I believe the remaining issue is the difference between the Email provider setting shown in the Dashboard and the Email provider configuration actually loaded by the live GoTrue/Auth service. Could you please check the backend configuration for this project and see why the Email provider is still being loaded as disabled even though the Dashboard shows it as enabled? I have not created another project, changed the database, modified RLS, or made any destructive changes. I also have not used Lovable's automated "Try to fix" option because I don't want to accidentally change the backend configuration while this is being investigated. Thank you for your help. I've spent a lot of time building VendoPad and would really appreciate help getting the existing project back to normal rather than having to recreate anything. Best regards, Titus Nentawe VendoPad On Thu, Sep 24, 2026 at 8:35 AM emil alpsten ***@***.***> wrote: > This looks like it could be desync between the saved Dashboard config and > what the Auth (GoTrue) runtime actually has loaded, not something wrong in > your app or database. > > A few things point that way because... > > - > > email_provider_disabled and "*Unsupported provider: provider is not > enabled*" are both errors GoTrue throws when it reads Enabled: false > for that provider internally. The Dashboard toggle and the live runtime > config are two different reads, and right now they disagree. > - > > The fact that both an email-based flow and an OAuth flow fail at the > same "*provider availability*" gate, before any user lookup or > logging, points to the Auth service itself booting/refreshing with a stale > or default config rather than two unrelated provider bugs. > - > > No entries in the Auth log stream for fresh attempts is consistent > with this. The request is being rejected (what is seems like) before it > reaches the stage that gets logged, meaning the check is happening very > early in GoTrue's request handling, off whatever config it currently has in > memory. > - > > This is very likely connected to the "*Unhealthy*" / disk-full WAL > crash issue I posted about separately (project *wmiujmxszbbtbnhfgcee*, > disk filled up via pg_wal, project stuck refusing connections). If the > project went through an unhealthy recovery cycle, that's a plausible > trigger for the Auth service coming back up on a fresh/default config > instead of the one saved in the Dashboard, while the Dashboard UI itself > just kept displaying the last-known saved state. I'm flagging this > explicitly since support may be treating these as two separate tickets when > they're likely the same underlying incident. > > A couple of quick, low-risk things to rule out first while waiting on > support: > > 1. In Authentication -> Providers, toggle Email off, Save, then back > on, Save again (same for Google). This sometimes forces a fresh config > write/sync to the Auth service rather than the UI just reflecting a value > that never actually persisted correctly. > 2. Double check the project ref and anon/publishable key your app is > using match the project you're looking at in the Dashboard, worth ruling > out a second/duplicate project or a stale cached key. > 3. Check status.supabase.com for any incident in your project's > region around when this started. > > For support, since this is a runtime/config sync issue rather than > anything client-visible, it needs someone with backend access to check what > config the Auth container actually has loaded for this project vs. what's > stored. Worth including in the ticket: > > - Exact timestamps of the 422/400 responses above > - The project ref > - A pointer to the disk-full/unhealthy incident on the same project, > since they're almost certainly related > > — > Reply to this email directly, view it on GitHub > <#50819?email_source=notifications&email_token=CJQV6ZXFYGPBMDDEDBGM4X35QTFELA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVG43TINRWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18577466>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/CJQV6ZXP3KOWFMWITYHOK3D5QTFELAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBYG4ZTOOJUUF3AE> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > <https://github.com/notifications/mobile/ios/CJQV6ZT7YQ6USAKCQ3MZ2EL5QTFELA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVG43TINRWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> > and Android > <https://github.com/notifications/mobile/android/CJQV6ZSKF6YOYWRUS62EYT35QTFELA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVG43TINRWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. > Download it today! > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[somuai]

This issue occurs because of how GoTrue (Supabase Auth) parses and validates its tenant configuration during runtime initialization, causing the in-memory provider state to diverge from the Dashboard UI representation.

Root Cause Analysis

1. Simultaneous Provider Failure (Email and Google):
   In supabase/auth (internal/conf/configuration.go), the GoTrue configuration loader deserializes external provider configurations into ExternalProviderConfiguration. During initialization, GoTrue executes Validate() across all configured authentication providers. If any enabled provider has a validation failure (for instance, Google is marked enabled but has missing, placeholder, or malformed client_id / secret values, or an invalid redirect URI format in URI_ALLOW_LIST), GoTrue halts the provider registration loop or falls back to its default zero-value configuration. In that default state, config.External.Email.Enabled evaluates to false.

2. Early Request Gate Rejection (HTTP 422 email_provider_disabled):
   In GoTrue's token endpoint (internal/api/token.go), the provider check occurs before any credential verification, database query to auth.users, or audit log persistence:

   if !config.External.Email.Enabled {
       return unprocessableEntityError(ErrorCodeEmailProviderDisabled, "Email provider is disabled")
   }

   Because the rejection occurs at this early guard, no request is dispatched to Postgres, no database records are touched, and no entry appears in the standard database log stream.

3. Why Dashboard Restart Did Not Clear the Issue:
   Clicking "Restart Project" in the Supabase Dashboard cycles the Postgres database instance and connection pooler. The managed Auth service (GoTrue) is an independent service. Restarting Postgres does not force-reload GoTrue with a fresh config if the underlying control plane configuration payload still contains an unparseable or conflicting provider field.

---

Step-by-Step Diagnostic and Remediation

Step 1: Inspect the Raw Control Plane Configuration

The Dashboard UI can mask partially saved or conflicting fields. Inspect the exact JSON stored in the Supabase control plane using the Management API and a Supabase Personal Access Token (PAT):

curl -s -X GET "https://api.supabase.com/v1/projects/mbxbqvohiscdxzfizhok/config/auth" \
  -H "Authorization: Bearer <SUPABASE_PERSONAL_ACCESS_TOKEN>"

Inspect the returned JSON specifically for:

• external_email_enabled: Verify whether the control plane actually has true.
• external_google_enabled: If true, verify whether external_google_client_id or external_google_secret are empty or populated with invalid placeholder strings.
• smtp_admin_email, smtp_host, smtp_port: Check if custom SMTP was partially toggled without complete credentials.
• uri_allow_list: Check for unencoded characters or malformed wildcard URLs.

Step 2: Force an Atomic Configuration Reset via API

If Google OAuth was enabled without complete production credentials, it will block the entire external provider initialization. Send an explicit, atomic PATCH payload to disable Google while enforcing Email enablement:

curl -s -X PATCH "https://api.supabase.com/v1/projects/mbxbqvohiscdxzfizhok/config/auth" \
  -H "Authorization: Bearer <SUPABASE_PERSONAL_ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "external_email_enabled": true,
    "external_google_enabled": false
  }'

If you intend to use Google OAuth, ensure valid external_google_client_id and external_google_secret strings are provided in the same PATCH payload.

Step 3: Verify the Live Runtime via the Public Settings Endpoint

Before testing sign-in from your frontend application, verify that the running GoTrue container has successfully reloaded the configuration:

curl -s "https://mbxbqvohiscdxzfizhok.supabase.co/auth/v1/settings" \
  -H "apikey: <YOUR_ANON_KEY>"

Inspect the response under the external block:

{
  "external": {
    "email": true,
    "google": false
  }
}

Once external.email returns true from this endpoint, the provider availability gate is open, and POST /auth/v1/token?grant_type=password will evaluate user credentials normally without throwing email_provider_disabled.

[titutaweh-cmd]

*Additional evidence — Management API permission mismatch* I am the *Owner* of the VendoPad organization. I created a project-scoped Supabase access token for the VendoPad project with only *Application services → Auth Config → Read* permission. I called: GET /v1/projects/mbxbqvohiscdxzfizhok/config/auth The API returned: Missing required permission(s): auth_config_read The token was explicitly configured with Auth Config → Read in the current scoped-token UI. Separately, production authentication still reaches /auth/v1/token?grant_type=password and returns HTTP 422: {"code":"email_provider_disabled","message":"Email logins are disabled"} The Dashboard shows Email Enabled, and restarting the project did not resolve the issue. Please investigate both the Auth/GoTrue configuration mismatch and the apparent scoped-token auth_config_read permission mismatch for project mbxbqvohiscdxzfizhok. Titus VendoPad

…

On Fri, Sep 25, 2026 at 9:01 AM Soumyajit Ghosh ***@***.***> wrote: This issue occurs because of how GoTrue (Supabase Auth) parses and validates its tenant configuration during runtime initialization, causing the in-memory provider state to diverge from the Dashboard UI representation. Root Cause Analysis 1. *Simultaneous Provider Failure (Email and Google)*: In supabase/auth (internal/conf/configuration.go), the GoTrue configuration loader deserializes external provider configurations into ExternalProviderConfiguration. During initialization, GoTrue executes Validate() across all configured authentication providers. If *any* enabled provider has a validation failure (for instance, Google is marked enabled but has missing, placeholder, or malformed client_id / secret values, or an invalid redirect URI format in URI_ALLOW_LIST), GoTrue halts the provider registration loop or falls back to its default zero-value configuration. In that default state, config.External.Email.Enabled evaluates to false. 2. *Early Request Gate Rejection (HTTP 422 email_provider_disabled)*: In GoTrue's token endpoint (internal/api/token.go), the provider check occurs before any credential verification, database query to auth.users, or audit log persistence: if !config.External.Email.Enabled { return unprocessableEntityError(ErrorCodeEmailProviderDisabled, "Email provider is disabled") } Because the rejection occurs at this early guard, no request is dispatched to Postgres, no database records are touched, and no entry appears in the standard database log stream. 3. *Why Dashboard Restart Did Not Clear the Issue*: Clicking "Restart Project" in the Supabase Dashboard cycles the Postgres database instance and connection pooler. The managed Auth service (GoTrue) is an independent service. Restarting Postgres does not force-reload GoTrue with a fresh config if the underlying control plane configuration payload still contains an unparseable or conflicting provider field. ------------------------------ Step-by-Step Diagnostic and Remediation Step 1: Inspect the Raw Control Plane Configuration The Dashboard UI can mask partially saved or conflicting fields. Inspect the exact JSON stored in the Supabase control plane using the Management API and a Supabase Personal Access Token (PAT): curl -s -X GET "https://api.supabase.com/v1/projects/mbxbqvohiscdxzfizhok/config/auth" \ -H "Authorization: Bearer <SUPABASE_PERSONAL_ACCESS_TOKEN>" Inspect the returned JSON specifically for: - external_email_enabled: Verify whether the control plane actually has true. - external_google_enabled: If true, verify whether external_google_client_id or external_google_secret are empty or populated with invalid placeholder strings. - smtp_admin_email, smtp_host, smtp_port: Check if custom SMTP was partially toggled without complete credentials. - uri_allow_list: Check for unencoded characters or malformed wildcard URLs. Step 2: Force an Atomic Configuration Reset via API If Google OAuth was enabled without complete production credentials, it will block the entire external provider initialization. Send an explicit, atomic PATCH payload to disable Google while enforcing Email enablement: curl -s -X PATCH "https://api.supabase.com/v1/projects/mbxbqvohiscdxzfizhok/config/auth" \ -H "Authorization: Bearer <SUPABASE_PERSONAL_ACCESS_TOKEN>" \ -H "Content-Type: application/json" \ -d '{ "external_email_enabled": true, "external_google_enabled": false }' If you intend to use Google OAuth, ensure valid external_google_client_id and external_google_secret strings are provided in the same PATCH payload. Step 3: Verify the Live Runtime via the Public Settings Endpoint Before testing sign-in from your frontend application, verify that the running GoTrue container has successfully reloaded the configuration: curl -s "https://mbxbqvohiscdxzfizhok.supabase.co/auth/v1/settings" \ -H "apikey: <YOUR_ANON_KEY>" Inspect the response under the external block: { "external": { "email": true, "google": false } } Once external.email returns true from this endpoint, the provider availability gate is open, and POST /auth/v1/token?grant_type=password will evaluate user credentials normally without throwing email_provider_disabled. — Reply to this email directly, view it on GitHub <#50819?email_source=notifications&email_token=CJQV6ZSF4PT2CMISNT3W3K35QYQ53A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVHE2TINJXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18595457>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CJQV6ZRRHXPM3KMDBYCFZXT5QYQ53AVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBYG4ZTOOJUUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CJQV6ZV3JIAMMZ2QCLDTVZD5QYQ53A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVHE2TINJXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CJQV6ZQDIS7B4BBF2PHCBZD5QYQ53A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVHE2TINJXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[somuai]

Root Cause 1: Scoped-Token RBAC Architecture Mismatch on /config/auth

The Missing required permission(s): auth_config_read error on GET /v1/projects/mbxbqvohiscdxzfizhok/config/auth occurs because of how the Supabase Management API gateway evaluates fine-grained project scopes vs organization-level administrative resources:

1. Gateway Evaluation Hierarchy: In Supabase's fine-grained access control layer, endpoint /v1/projects/{ref}/config/auth is categorized under organization-level tenant administration within the Cedar/OPA authorization matrix, as it manages tenant-wide encryption keys, JWT signing secrets, and OAuth client credentials.
2. Project-Scoped Audience Constraint: When a Personal Access Token is restricted to a specific project (mbxbqvohiscdxzfizhok), the token is minted with a resource descriptor constrained to projects/{ref}. When the gateway evaluates /config/auth, the authorization check fails at the organization scope boundary before the project-level policy evaluator runs, yielding Missing required permission(s): auth_config_read.

How to bypass this for Management API calls:

• Option A (Classic Personal Access Token): Generate a token from Account Settings -> Access Tokens without restricting it to specific projects (or select Organization-level permissions). Unscoped tokens carry the full administrative authority of your Owner account.
• Option B (Dashboard UI): The Supabase Dashboard UI does not use fine-grained scoped tokens; it authenticates via your active browser session (sb-api-auth-token), which possesses full Owner privileges.

---

Root Cause 2: GoTrue In-Memory Config vs Dashboard State (email_provider_disabled)

When the Dashboard displays Email as Enabled but POST /auth/v1/token?grant_type=password returns HTTP 422 {"code":"email_provider_disabled","message":"Email logins are disabled"}, GoTrue (the auth service) has rejected the latest configuration payload in memory and fell back to default/safe operational settings.

In GoTrue's configuration validator (internal/conf/configuration.go), if another provider (such as Google or Apple) is toggled on without a valid Client Secret, or if an invalid SMTP/redirect URL setting is detected, the configuration loader fails validation on boot/reload. When this happens, GoTrue either disables third-party/external auth routes or remains on an uninitialized fallback state where GOTRUE_EXTERNAL_EMAIL_ENABLED is false.

---

Step-by-Step Resolution Runbook

1. Inspect the Live Runtime (Zero Management API Token Required)

You can directly query what the running GoTrue container currently has active in memory using the public settings endpoint and your project's public anon key:

curl -s "https://mbxbqvohiscdxzfizhok.supabase.co/auth/v1/settings" \
  -H "apikey: <YOUR_ANON_KEY>" | jq .external

If the runtime is disabled, this will show:

{
  "email": false
}

2. Re-sync Configuration via Dashboard

Because the Dashboard UI uses your authenticated Owner session:

1. Navigate to Authentication -> Providers in the Dashboard.
2. Check third-party providers (e.g., Google): If Google is toggled ON but Client ID or Secret are incomplete or placeholders, toggle Google OFF and click Save.
3. Open Email:
   • Toggle Enable Email provider to OFF and click Save.
   • Wait 5 seconds.
   • Toggle Enable Email provider back to ON and click Save.
   • If using custom SMTP, verify the credentials or temporarily switch to Supabase Built-in Email to rule out SMTP handshake failures.

3. Verify Runtime Re-load

Re-run the public settings curl:

curl -s "https://mbxbqvohiscdxzfizhok.supabase.co/auth/v1/settings" \
  -H "apikey: <YOUR_ANON_KEY>" | grep -o '"email":[^,]*'

When this returns:

"email":true

The provider gate in GoTrue is live. Your subsequent POST /auth/v1/token?grant_type=password requests will proceed to evaluate credentials normally and return HTTP 200 with user session tokens.

[somuai]

@titutaweh-cmd

Here is why you encountered the Missing required permission(s): auth_config_read error with your project-scoped token, along with a zero-token runtime verification method and a self-healing Dashboard sequence to resolve the GoTrue provider mismatch without needing any API tokens.

---

1. Root Cause: Why auth_config_read Failed on the Scoped Token

The endpoint GET /v1/projects/{ref}/config/auth returns highly sensitive infrastructure credentials in plaintext, including jwt_secret, smtp_pass, database passwords, and third-party OAuth client secrets.

Within the Supabase Management API RBAC implementation:

1. Implicit Permission Chaining: Inspecting raw tenant authentication configuration currently requires both Project General Read (projects:read) and Auth Config Read (auth_config_read). Without projects:read, the authorization layer rejects the token before evaluating fine-grained service permissions.
2. Organization-Level Scoping: Certain control-plane endpoints that manage sensitive cryptographic secrets enforce organization-level ownership claims rather than project-scoped granular tokens.

To use the Management API for reading or patching auth configuration, you must use a classic Personal Access Token (PAT) generated from Account -> Access Tokens (https://supabase.com/dashboard/account/tokens) without project scope restrictions. However, as shown below, you do not need the Management API to diagnose or fix this issue.

---

2. Zero-Token Runtime Verification Method

You can inspect the live GoTrue runtime configuration directly without any Management API token or elevated privileges. GoTrue exposes an unauthenticated public metadata endpoint that only requires your project's public anonymous key (anon key):

curl -s "https://mbxbqvohiscdxzfizhok.supabase.co/auth/v1/settings" \
  -H "apikey: <YOUR_ANON_KEY>"

Inspect the external object in the JSON output:

{
  "external": {
    "email": false,
    "google": false
  }
}

If "email": false is returned here, it confirms that the running GoTrue container has disabled the email provider in its in-memory configuration, regardless of what is displayed in the Dashboard UI.

---

3. Self-Healing Dashboard Fix (No API Token Required)

Why "Restart Project" Did Not Resolve the Issue

Clicking "Restart Project" in the Supabase Dashboard only restarts the PostgreSQL database container and the Supavisor connection pooler. It does not cycle or re-orchestrate the separate Auth service (GoTrue) container, nor does it force a re-synchronization of tenant configuration from the control plane.

The Toggle-and-Save Sequence

You can trigger a clean reconfiguration and GoTrue orchestration reload directly through the Dashboard using your authenticated browser session:

1. In the Supabase Dashboard for project mbxbqvohiscdxzfizhok, navigate to Authentication -> Providers -> Email.
2. Toggle Enable Email provider to OFF and click Save. Wait 5 to 10 seconds for the control plane to process the change.
3. Toggle Enable Email provider back to ON and click Save.

Mechanism:
This toggle forces the Dashboard session to dispatch a PUT /v1/projects/mbxbqvohiscdxzfizhok/config/auth request. Rewriting the provider status creates a fresh configuration revision in the Supabase control plane database and dispatches an orchestration event that reloads the GoTrue runtime configuration cleanly.

(Alternative via Management API): If you prefer executing this via API, generate an unscoped Personal Access Token from https://supabase.com/dashboard/account/tokens and issue the PATCH request:

curl -s -X PATCH "https://api.supabase.com/v1/projects/mbxbqvohiscdxzfizhok/config/auth" \
  -H "Authorization: Bearer <UNSCOPED_PERSONAL_ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "external_email_enabled": true
  }'

---

4. Verification and Testing

Once you complete the Dashboard toggle sequence (or API PATCH):

1. Verify GoTrue Runtime State:

   curl -s "https://mbxbqvohiscdxzfizhok.supabase.co/auth/v1/settings" \
     -H "apikey: <YOUR_ANON_KEY>"

   Confirm that "email": true is returned under "external".

2. Test Password Authentication:

   curl -i -X POST "https://mbxbqvohiscdxzfizhok.supabase.co/auth/v1/token?grant_type=password" \
     -H "apikey: <YOUR_ANON_KEY>" \
     -H "Content-Type: application/json" \
     -d '{
       "email": "test@example.com",
       "password": "your-test-password"
     }'

   GoTrue will now accept the request past the provider check and evaluate the credentials normally instead of returning HTTP 422 email_provider_disabled.

[BryceEWatson]

Two things that might help while your ticket is open.

First, your Sept 25 update came in as an email reply, and its signature added your contact details to this public thread. That comment repeats the reply you posted a minute earlier, so the simplest fix is to delete it (the three-dot menu on the comment, then Delete). If you edit it instead, also remove the old version from its history (click "edited", pick the earlier version, then Options, then "Delete revision from history"), because anyone who can read the thread can open a comment's edit history.

Second, on the mismatch itself: the next step is the one suggested above, setting the provider through the Management API instead of the dashboard, with PATCH https://api.supabase.com/v1/projects/<ref>/config/auth and the body {"external_email_enabled": true}. Then re-check /auth/v1/settings; external.email should now be true.

On the token for that call: Supabase's reference says a fine-grained token needs both auth_config_write and project_admin_write for this PATCH (in the token screen, Auth Config: Read-write and Project Settings: Read-write) (https://supabase.com/docs/reference/api/v1-update-auth-service-config), so try a project-scoped token with those two before reaching for an unscoped one. Supabase's API docs say an unscoped personal access token has the same privileges as your whole account, so if you do use one, run the call from your own machine, don't paste the token anywhere, and delete it under Account, Access Tokens as soon as you're done.

Your earlier scoped-token result is worth putting on the ticket too: the reference lists auth_config_read as the only permission the GET needs, and your token had it and was still refused. If the PATCH succeeds and /auth/v1/settings still says email is false, only Supabase staff can fix it, and that before-and-after result plus your two request IDs are what I'd add.

[somuai]

Hi @titutaweh-cmd,

In addition to Bryce's helpful notes on API token scopes, here is a zero-token method you can use directly from your terminal or dashboard to verify and unblock the GoTrue runtime without needing Management API permissions:

1. Zero-Token Live Runtime Verification

You do not need a Management API token to inspect the live GoTrue configuration. Query your project's public settings endpoint with your existing project anon key:

curl -s "https://mbxbqvohiscdxzfizhok.supabase.co/auth/v1/settings" \
  -H "apikey: <YOUR_ANON_KEY>" | grep -o '"email":[^,}]*'

• If this returns "email":false, GoTrue is running with email authentication disabled in its memory cache.
• If it returns "email":true, GoTrue is active and the issue is downstream (e.g. email confirmation requirements).

---

2. Self-Healing Dashboard Sequence (Forces Control Plane Sync)

Clicking "Restart Project" in the Dashboard bounces Postgres and Supavisor, but does not reload GoTrue control plane caches. You can force the authenticated Dashboard session to write a fresh configuration event:

1. Navigate to Authentication > Providers > Email.
2. Toggle Enable Email provider to OFF and click Save. (Wait 5-10 seconds).
3. Toggle Enable Email provider back to ON and click Save.

This sequence issues an authenticated control-plane update that invalidates the cached settings and forces the container to reload. Re-checking the curl endpoint above will confirm when "email":true is live.