Skip to Content
Security & privacyAuthentication, admission and ownership

Developer reference

Identity, admission and ownership

Separate provider identity, application access and database policies when reviewing private operations.

Provider authentication verifies identity. Application admission determines whether that identity may use Helm. Ownership limits the records that identity can read or change.

Registration modes

The public reviewer-facing product uses open registration. Other installations can choose closed or allowlist modes. Closed registration does not revoke existing admitted users; allowlist registration requires confirmed email and matching provider confirmation settings.

Signup’s neutral response does not establish a verified financial session. Check the actual owned session before admitting a UI to private data.

Owned sessions

Provider tokens are checked against actual provider session identity. Local revocation denies that session. Global revocation denies old registered and unregistered sessions; a later valid sign-in can establish a new session.

When verification is unavailable, retain the distinction from a known signed-out state and conceal private content.

Database policies

Row-level ownership and service permissions support the API boundary. A public Supabase project key is not a privileged service credential. A service-role client can bypass policies, so keep it server-only and explicitly scope its operations.

Review an operation

Check identity, admission, scope and owned resource together. A resource ID or a private route is not sufficient permission. Test a wrong-user resource refusal as well as the allowed case.

See API authentication, data boundary and test inventory.