@@ -526,7 +526,7 @@ SMTP_PASS=...
   Copies already in a browser cache stay until their one-year `immutable`
   entry expires. See Migration for existing objects.
 
-- **Supabase refuses a connected app's token.** Run
+- **Supabase refuses a connected app's token on the Data API, Storage and Realtime.** Run
   `packages/supabase/scripts/31-connected-app-token-gate.sql` once, or push
   the paired migration `20260928120000_refuse_connected_app_tokens`. The Data
   API answers `403` with the code `connected_app`. Storage and Realtime refuse
@@ -545,6 +545,17 @@ SMTP_PASS=...
   [configuration](../../docs/self-hosting/configuration.md#turn-off-password-sign-in)
   says. It stays off on the local stack.
 
+- **The MCP reference names what the Supabase gate covers ([#441](https://github.com/docs-plus/docs.plus/issues/441)).**
+  [The reference](../../docs/mcp/reference.md#authorization) said that
+  Supabase refuses a connected app's token, with no limit. The gate covers only
+  the Data API, Storage and Realtime. The Supabase Auth API has no such check,
+  so the reference now points to the password sign-in hook. In production, also
+  turn on Secure password change, as
+  [configuration](../../docs/self-hosting/configuration.md#turn-off-password-sign-in)
+  says. The local `packages/supabase/config.toml` now sets
+  `secure_password_change = true`. A running local stack takes it after a
+  Supabase stop and start.
+
 - **Outside development, `getErrorResponse` answers every 5xx with `Internal server error`.**
   The `code` is unchanged, and the server logs the original. A Prisma or
   Supabase message used to reach production `500` responses. A handler that
 
@@ -23,7 +23,8 @@ Replace `<PUBLIC_RESTAPI_URL>` with your server's value of [`PUBLIC_RESTAPI_URL`
 - Send the token as `Authorization: Bearer <token>`. Replace `<token>` with the access token the host gets at the end of the OAuth flow. The `token` header that other REST routes read is ignored here.
 - Only a token that carries a `client_id` claim is accepted. An OAuth grant adds that claim. A docs.plus browser session token never has it, so it gets `401`.
 - On the docs.plus server, only `/api/mcp` accepts a token with `client_id`. [Authentication](../api/authentication.md#what-each-credential-can-call) says what the other routes do with it.
-- The docs.plus Supabase project refuses a token with `client_id` too. The Data API (tables, RPC and GraphQL) answers `403` with the code `connected_app`. Storage shows the token no objects and refuses its uploads. Realtime refuses it on private channels, and applies the same refusal to database-change subscriptions. So build on the tools below, not on the Supabase APIs. A self-hosted server needs [one Supabase script](../self-hosting/configuration.md#turn-on-the-mcp-connector) for this.
+- The docs.plus Supabase project refuses a token with `client_id` on the Data API, Storage and Realtime. The Data API (tables, RPC and GraphQL) answers `403` with the code `connected_app`. Storage shows the token no objects and refuses its uploads. Realtime refuses it on private channels, and applies the same refusal to database-change subscriptions. So build on the tools below, not on the Supabase APIs. A self-hosted server needs [one Supabase script](../self-hosting/configuration.md#turn-on-the-mcp-connector) for this.
+- The Supabase Auth API has no `client_id` check. The [password sign-in hook](../self-hosting/configuration.md#turn-off-password-sign-in) refuses every password sign-in, so a password that a connected app sets cannot open a session. A self-hosted server must turn that hook on too.
 
 **Audience binding is not possible today.** Supabase always sets `aud` to `authenticated`. It never writes the RFC 8707 `resource` into the token ([supabase/auth#2610](https://github.com/supabase/auth/issues/2610)). So `/api/mcp` cannot prove that a token was issued for it. The `client_id` rule is the strongest check Supabase allows.
 
 
@@ -235,6 +235,8 @@ The function is a Custom Access Token hook, which every Supabase plan has. It re
 
 **Hosted Supabase.** In the Supabase dashboard, open **Authentication > Hooks**. Add the **Customize Access Token (JWT) Claims** hook, choose **Postgres**, and pick that function. The hook runs each time Supabase issues a token. If sign-in or a token refresh fails after you turn it on, turn the hook off again.
 
+**Secure password change.** In the same dashboard, open the **Email** provider settings and turn on **Secure password change**. It asks for a recent sign-in before a password change. Supabase counts a session under 24 hours old as recent, so this setting is only an extra layer. The hook is the control that refuses a password sign-in.
+
 **Local stack.** `packages/supabase/config.toml` has the hook block, commented out.
 
 ```toml
 
@@ -206,7 +206,7 @@ double_confirm_changes = true
 # If enabled, users need to confirm their email address before signing in.
 enable_confirmations = false
 # If enabled, users will need to reauthenticate or have logged in recently to change their password.
-secure_password_change = false
+secure_password_change = true
 # Controls the minimum amount of time that must pass before sending another signup confirmation or password reset email.
 max_frequency = "1s"
 # Number of characters used in the email OTP.