Access Model
Understanding how access works on the OSDU Data Platform at Equinor.
Two layers of access
To work with data on OSDU, you need two separate things: platform access and data access. They serve different purposes and are managed independently.
Platform access determines whether you can connect to OSDU and call its APIs at all. Without it, you cannot reach any service. With it, you can make API calls — but you still can't see any data unless you also have data access.
Data access determines which specific records you can read or write. Every record in OSDU is protected by access groups defined in its ACL (Access Control List). Being on the platform does not automatically mean you can see all data.
This separation exists because platform connectivity and data visibility are different concerns. A user may need to call APIs without seeing sensitive datasets, or may need access to one dataset but not another.
Users and applications
There are two ways to authenticate with OSDU:
Users (interactive login) — you log in with your Equinor account. This includes apps that use user impersonation (e.g. OSDU CLI, Python SDK with interactive login). ADME checks your personal identity for access.
Applications (client credentials) — your app authenticates with its own identity using a client_id and client_secret from an app registration in Entra ID. ADME checks the app's service principal for access.
The access model applies the same way to both — the difference is in how they authenticate and how access is requested.
Environments
Equinor runs three OSDU environments on Azure Data Manager for Energy (ADME):
| Environment | Purpose | URL |
|---|---|---|
| Development | Experimentation and pipeline building | https://equinorswedev.energy.azure.com |
| Test | Integration and validation | https://equinorswetest.energy.azure.com |
| Production | Governed data for the organisation | https://equinorswe.energy.azure.com |
Platform access is granted per environment — read access to Development does not give you read access to Production. Data access groups, however, are shared across all three environments.
Read and write
Each layer (platform and data) has read and write levels:
- Read lets you call OSDU APIs and query/retrieve records
- Write lets you create, update, and delete records
Write access always requires read access as a prerequisite. At the data level, write access is controlled through owner groups — separate from the viewer groups used for read access.
Production write access requires completing the Production Readiness Checklist before it can be granted.
ACLs — how records are protected
Every record in OSDU has an ACL with two lists:
- Viewers — groups that can read the record
- Owners — groups that can read, write, update, or delete the record
These groups correspond to Entra ID groups managed by the Data Office. When you join a group, you gain access to all records that list that group in their ACL — across all environments.