Authentication
Give each application a credential with a clear purpose. Manage database identities and permissions, then verify the access your application actually uses.
Authenticate the request
When required by your instance
Database-user read controls
Console membership, database access and service operations have different responsibilities. Keep their credentials distinct.
Authenticate engine HTTP requests to a specific instance and tenant. Personal tokens inherit the member’s effective access; choosing read/write cannot increase it.
Identify the database user whose roles, grants and read policies apply. HTTP uses the user’s API key; a per-user SQL listener uses its login password.
Authenticate supported organization and control-plane operations, including managed embeddings. Keep this separate from credentials that query your database.
Adding someone to your organization’s Team does not itself grant database permissions.
Database access
Use database roles and read controls to decide what an identity can retrieve from your tables. Keep the policy close to the data it protects.
Explore database accessCheck an allowed operation and a denied one on each query path your application uses. An administrative bearer does not demonstrate restricted access.
Group database responsibilities into roles. Review inherited roles and object scopes, then grant the table access each identity needs.
Define read conditions for a table and role. On the documented database-user read path, records that do not satisfy the condition are filtered out.
Configure masks for sensitive columns. Read policies evaluate the underlying values before masking shapes the returned fields.
Keep credentials tied to an owner and purpose, with a clear process for changing or removing access.
Use the credential offered by Connect. Where access tokens are supported, choose the owner and required permissions, then save the shown-once secret.
Copy the complete OC_URL and the credential for OC_TOKEN from Connect. Keep the URL unchanged, load secrets on your server and test the expected access.
Update clients with a replacement token, test it and revoke the old one. Check the returned status, wait for any pending engine confirmation and test that the old credential is refused.
Token changes need confirmation. Revocation can reach running engines asynchronously. A successful management response alone does not establish that every engine has applied the change.
Follow the credential guideFind the connection details and controls that match your application.
Before you connect
Use the credential supplied by Connect: an access token where supported, or the
instance key on other configurations. Where database identity is required, also send
both X-OC-DB-User and X-OC-DB-Key. A bearer-only request is
not evidence that database-user row policies or masks were applied.
A personal instance token can carry read-only access, enforced by the service. Selecting read/write does not exceed the member’s effective permissions. Verify the expected allowed and denied operations using the actual token and interface your application uses.
Removing a member or leaving an organization revokes that member’s personal instance tokens. Check the Team page for any pending confirmations across instances. Organization API keys and database identities are separate; review them and other shared credentials as part of offboarding.
The connected console exposes network address rules and authorization audit history for the selected instance. Confirm the applied state and available capabilities there. An empty HTTPS IP access list allows requests from any address; it does not open a SQL wire listener. Read the access and network guidance.
Build with OriginChainDB
