Users and access
DataHub does not hold user accounts. Identity lives in your existing OAuth2/OIDC identity provider, and DataHub reads the caller's roles and data set grants from your provider on every request.
The practical consequence: joiners, movers and leavers are handled by the process you already have, and granting or revoking access takes effect within about a minute, without waiting for the user's token to expire.
How a user reaches the platform
Through whatever the organisation already uses, single sign-on, MFA, conditional access. DataHub is not involved.
The token carries the user's identity, their organisation, and their roles.
This resolves which tenant the request belongs to, and therefore which databases it touches.
These determine what the user may read and write. Data set permissions →
Because this is evaluated per request, a change made in your identity provider takes effect within about a minute, with no restart and no need to sign anybody out.
The baseline role
Access to the platform at all requires the DATAHUB_ACCESS role. Without it, a user
authenticates successfully and can do nothing, which is the correct default for anyone
whose access has not been deliberately granted.
Beyond that, permissions are granular: data set permissions grant read and write on the stored data, independently of each other, through organization groups. → How grants work
Access tokens
Every user can copy their access token from the user menu at the top right of the console. It is used for sending data in from a script or an integration.
Three rules worth stating to users explicitly:
- It is a credential. It carries the holder's full permissions. Treat it exactly like a password.
- It expires. Tokens are short-lived by design. A script that stores one and runs for months will fail, which is the intended behaviour, not a bug to work around.
- It is not for production integrations. A person's token ties a production data feed to an individual's employment. Use a service account.
Service accounts
Production ingestion and machine-to-machine integrations should use dedicated service accounts in your identity provider, with their own credentials and their own roles. A durable data subscription is an integration like any other and should hold its own service account.
The permission model supports a pattern worth using deliberately: write does not imply read. An ingestion service account can be granted write on the data sets it feeds without being able to read anything back. If those credentials are ever compromised, the blast radius is limited to writing rather than to exfiltration.
Recommended shape for an ingestion account:
| Identity | A dedicated service account, named for the source system it represents |
| Organisation membership | Its service-account user must be a member of the tenant's organisation |
| Data set grants | Write on the specific data sets it feeds. No read, unless it genuinely needs it |
| Source-side access | Read-only on the source system it reads from |
| Credential rotation | Through your identity provider's normal process |
The membership row is the one that produces confusing support tickets, because two different mistakes look alike from the client:
| Symptom | Cause |
|---|---|
| Rejected on every call, credentials look fine | Not a member of any organisation. Membership is what tells DataHub which tenant the account belongs to, so without it there is no tenant to serve and the call is refused rather than merely empty. |
| Connects, but every list comes back empty | A member, but with no data set grants. Identity is fine; access is missing. |
The first looks like a credential problem and is not. The second looks like a data problem and is not.
Sessions
The console holds sessions server-side, externalised to a shared store so that any instance can serve any request. Sessions end automatically after a period of inactivity, and the console tells the user why when it happens.
Because sessions are externalised, the console can be restarted or scaled without signing everybody out, and the load balancer needs no session affinity.
Reviewing access
Two practical habits:
- Review data set grants quarterly. The group names carry the data set they grant, so the group list in your identity provider is a readable access report, no export from DataHub required.
- Watch for over-broad grants. Roles granting read or write across all data sets exist as an operator escape hatch. They should be held by very few accounts, and their holders should be reviewed by name. Remember that a grant high in the data set hierarchy covers everything beneath it.
What administrators cannot do from the console
By design, a few things live outside the platform:
- Creating users, in your identity provider
- Assigning roles and data set groups, in your identity provider
- Provisioning tenants, infrastructure work → Organisations and tenants
This is deliberate. Identity and infrastructure belong to systems built for them, with their own audit trails and approval processes, rather than being duplicated inside an application.
- Data set permissions: how grants are expressed, in detail
- Organisations and tenants: how the organisation claim resolves
- Security and compliance: the wider posture
- Change data capture: service accounts for source-system integrations