LLearnCode
Academy/supabase/Platform and authority

intermediate · 22 minute study

Identity is not authority

A signed-in user can still be the wrong user, in the wrong company, with the wrong permission. A public key and a privileged key must never be treated as interchangeable fixes.

Loading progressEvidence grows with practice
Useful preparation · 1 prerequisite

Use this as a map, not a lock. If these ideas are familiar, continue.

  • Find the database behind the API — An SDK call hides several boundaries. Understanding them helps you debug denied rows without randomly changing keys, policies or browser code.

First, build a mental model

A principal is the actor the server has verified. Authorization is a separate question about a specific action on a specific resource.

  1. A typical signed-out Data API request uses the anon role. A signed-in user's request uses authenticated, but that role alone does not prove membership or permission.
  2. Supabase anonymous sign-ins also create authenticated users. The database role is not a reliable shortcut for a person's account type or business entitlement.
  3. Use publishable keys for shipped client components. Secret keys and legacy service_role credentials grant elevated authority and must remain in controlled server code.
  4. Do not trust user-editable profile metadata as authorization evidence. Keep membership and role decisions in a trusted authority and account for stale session claims.
Read the codetext · educational example
Alice: verified user ID + company A membership
Bob:   verified user ID + company B membership
Guest: no verified user ID

Alice + note in A + SELECT grant + matching policy → visible
Alice + note in B + SELECT grant + tenant policy   → filtered
Authenticated alone                              ≠ company access
  1. Authentication

    Verify that the actor is Alice rather than trusting a submitted userId.

  2. Resource scope

    Resolve the company's identity from the actual note.

  3. Authorization

    Compare trusted membership and the required operation, not only 'is signed in'.

Production thinking

Take this beyond the example.

When reading existing repositories, distinguish current publishable/secret key guidance from legacy anon/service_role variable names. Never copy real credential values into lessons or use a privileged key to make a browser error disappear.

Sources and further reading

Your evidence

unseen is a local learning signal, not a credential or proof of production competence.

Explain the mental model, then explicitly acknowledge it. Opening a page is not evidence.

Supported retries can complete this lesson. Independent evidence and delayed review determine the skill stage.

Next lesson · Predict the rows a policy will reveal →