Skip to content
Start free
All products

Authentication & access control

Access starts
with identity.

Connect applications as database users, then define what those users can read.

Start free Read the access guide

Identify the caller. Shape the result.

Roles, row policies and column masks determine which records and fields a database user can read.

Read access for a restricted database userIllustrative example
Authenticated database usersupport_7
Role Support reader Read request · customers
01

Stored records

customer-01Assigned to support_7
customer-02Assigned to support_9
customer-03Assigned to support_7

The source table stays intact.

Read policy

  1. 1Check table access
  2. 2Keep assigned rows
  3. 3Mask private fields
02

Returned view

customers2 eligible rows
customer-01
emailMasked
customer-03
emailMasked
Fields filtered for this caller

A restricted view of the same data.

  1. Choose the credential

    A database-user key identifies the caller so requests can use that user's roles and grants.

  2. Define the view

    Grant table access, filter eligible rows and mask sensitive columns. A support role could read assigned customers while their private fields remain hidden.

Use a service-enforced read-only token when an application must not write.

Explore row policies

Why OriginChainDB

Permissions close to the data

Define database roles and table access alongside the records they protect.

Roles and grants

Precise read access

Filter rows and mask columns without maintaining a separate copy of each table for every role.

Policies and masking

Credentials with ownership

Rotate or revoke a personal token independently of the shared database bearer.

Credential lifecycles
Design the access model

One table.
Different responsibilities.

Start with the job each caller needs to do. Give support a view of assigned customers; give an analyst the records needed for reporting.

This example combines table read access, row filtering and field masking. The roles are illustrative, not built-in defaults.

Build a row policy
Example · customer read permissions
RoleRows returnedEmail field
Support readerAssigned customersMasked
Regional analystCustomers in their regionMasked
Contact managerAssigned customersVisible

Check the result as the intended database user. An administrative bearer is not a test of restricted access.

Credentials over time

Know who connects.
Know how to revoke access.

Keep each credential tied to its purpose and owner, from the first connection through offboarding.

  1. 01

    Issue

    Choose the identity and credential type for the application or person.

  2. 02

    Store

    Save a newly issued secret in your secret manager when it is shown.

  3. 03

    Rotate or revoke

    Update clients using a shared bearer. Personal-token changes affect that token independently.

Team membership ≠ database identity

Removing an organization member does not itself delete their personal tokens. Review database users and shared credentials as part of offboarding.

Read the offboarding guidance

Put it to work.

Separate team and database access

Organization membership and database identity are separate. Adding someone to your team does not grant permission to query records.

Understand identities

Verify access in your application

Check how each query path applies the user's roles and policies. Recorded write grants alone do not prevent writes.

Review enforcement

Build with OriginChainDB.

Start free Read the access guide