We already have Auth0 and row-level security. What does this add?
- Date
- By
- CipherStash Team
A layer below them. Your identity provider says who is asking. RBAC decides what they may attempt. Database grants and RLS decide which rows come back. Once a query is allowed, the database returns plaintext. CipherStash decides whether a value can become plaintext, and for whom, inside the key derivation. You keep the other layers.
The layers
Identity. Your identity provider tells you who is asking. It says nothing about data.
Application permissions. RBAC or ABAC decides what a caller may attempt. It is enforced in application code, and bypassed by anything that reaches the database another way.
Database grants. What a database principal can reach. Usually the application's service account, which can reach everything.
Row-level security. Which rows a query returns for a given principal. The rows it returns are in the clear.
CipherStash. Whether the values in those rows can be decrypted, and for whom.
The gap the first four leave is at the bottom. Once a query is allowed, the database reads and returns plaintext. A leaked service credential, a backup, a read replica, a support tool, an agent with a connection string: all of them see the same plaintext the application sees, because the checks live above the data.
How the last layer works
Every value is encrypted under its own key. Deriving that key needs ZeroKMS to authorize the request, and the request carries an identity. With OIDC federation the request is made as the signed-in user, and a value can be locked to that user so only they can decrypt it. Your own backend, holding valid workspace credentials, cannot decrypt another user's locked values.
RLS is the closest neighbour, and the two compose. On Supabase, RLS controls which rows a caller may query and encryption controls whether the values in those rows can be read.