Skip to content

Entra ID Integration

OSDU uses its own entitlements system to control who can access services and data. At Equinor, we integrate this with Microsoft Entra ID so that access is managed centrally — you don't need to maintain user memberships in two places.

graph TD subgraph before ["Without Entra ID Integration"] direction TB U1["User"]:::user -->|"added manually"| EID1["Entra ID"]:::identity U1 -->|"added manually"| OSDU1["OSDU Entitlements"]:::orange EID1 -.->|"must be kept in sync ❌"| OSDU1 M1["Manage access in two places"]:::red end subgraph after ["With Entra ID Integration"] direction TB U2["User"]:::user --> EID2["Entra ID"]:::identity EID2 -->|"automatically synced"| OSDU2["OSDU Entitlements"]:::green M2["Single source of truth"]:::green end classDef user fill:#f3e5f5,stroke:#6a1b9a classDef identity fill:#e3f2fd,stroke:#1565c0 classDef orange fill:#fff3e0,stroke:#e65100 classDef red fill:#ffebee,stroke:#c62828 classDef green fill:#e8f5e9,stroke:#2e7d32

The goal: instead of managing users separately in both Entra ID and OSDU, Entra ID becomes the single source of truth. Access is granted, revoked, and audited in one place — changes flow through to OSDU automatically.

Currently available for dev and test only

Entra ID integration is live for the dev and test environments. Production does not yet support Entra ID integration — users need to apply for access through AccessIT and use the old per-instance scope. See the migration checklist for details.

How it works

Entra ID security groups can be added as members of OSDU entitlement groups. When a user calls an OSDU API, the entitlements service checks the user's Entra ID group memberships at runtime via Microsoft Graph. If the user belongs to an Entra ID group that is a member of the required OSDU group, access is granted.

graph LR A[User joins Equinor] --> B[Added to Entra ID groups] B --> C[Entra ID groups are members of OSDU groups] C --> D[User has OSDU access]

This means:

  • Users get access automatically when they are added to an Entra ID group — no separate OSDU onboarding step is needed (currently dev and test only)
  • Access is revoked automatically when a user is removed from the Entra ID group
  • Dynamic group membership in Entra ID (e.g. based on department or job title) flows through to OSDU

What this means for Equinor users

When you join Equinor, your account is added to Entra ID groups that map to OSDU platform groups. This is why you automatically receive read access to the dev and test environments without applying for anything. For production, you need to apply for read access through AccessIT — see the step-by-step guide.

graph TD subgraph Entra ID EG1[All Equinor employees group] EG2[Data Office Norway group] end subgraph OSDU OG1[users.datalake.viewers] OG2[data.office.norway.viewers] end EG1 -->|member of| OG1 EG2 -->|member of| OG2 OG1 -->|grants| P[Platform read access] OG2 -->|grants| D[Read access to Norway data]

The same model applies to data access. Data office groups in OSDU can have Entra ID groups as members, so when you are granted access to a data office group via AccessIT, the underlying mechanism is Entra ID group membership.

How access decisions are made

sequenceDiagram participant User participant OSDU as OSDU API participant Entitlements as Entitlements Service participant Graph as Microsoft Graph User->>OSDU: API request + Bearer token OSDU->>Entitlements: Check caller's group membership Entitlements->>Graph: Resolve Entra ID group memberships Graph-->>Entitlements: Group membership list Entitlements-->>OSDU: Access granted / denied OSDU-->>User: API response

This check happens at runtime — there is no sync or replication of group data. Changes to Entra ID group membership take effect immediately.

Applications and client credentials

Entra ID group resolution only works for delegated (user) tokens. Applications using client credentials are not resolved through Entra ID groups and must be added directly as members of the required OSDU groups. The new unified scope (https://energy.azure.com/.default) works for client credentials as well — see the migration checklist for details.

Further reading

Last update: 2026-03-02