Skip to content

Entra ID Integration — Migration Checklist

We are rolling out Entra ID integration for the OSDU platform. If you authenticate using the authorization code flow (delegated/user tokens), you need to update your token scope.

Dev and test only — not yet supported for production

Entra ID integration is currently available for the dev and test environments only. Production does not yet support Entra ID integration and still uses the old per-instance resource ID scope. Do not update your prod configuration until further notice.

Client credentials flow

The new unified scope also works for the client credentials flow. Apps using client credentials should update their scope to https://energy.azure.com/.default.

graph LR U[User]:::user -->|auth code flow| EID[Entra ID]:::identity EID -->|old scope| OLD["❌ {per-instance ID}/.default"]:::old EID -->|new scope| NEW["✅ https://energy.azure.com/.default"]:::new NEW --> ADME[ADME Platform]:::platform classDef user fill:#f3e5f5,stroke:#6a1b9a classDef identity fill:#fff3e0,stroke:#e65100 classDef old fill:#ffebee,stroke:#c62828 classDef new fill:#e8f5e9,stroke:#2e7d32 classDef platform fill:#e3f2fd,stroke:#1565c0

To understand why we are making this change and how Entra ID integration works, see Entra ID Integration.

What's changing

When obtaining a delegated token via the authorization code flow, the scope is changing from a per-instance resource ID to a unified scope:

Old scope New scope
Dev 7daee810-3f78-40c4-84c2-7a199428de18/.default https://energy.azure.com/.default
Test 5a1178c2-5867-4a34-8fb8-216164e30b5f/.default https://energy.azure.com/.default
Prod 5a1178c2-5867-4a34-8fb8-216164e30b5f/.default Not yet available — continue using old scope

The new scope applies to dev and test only. Production does not yet support Entra ID integration.

Checklist

1. Update your CLI config files

Open each config file in ~/.osducli/ (or C:\Users\<YourUsername>\.osducli\ on Windows) and update the scopes line:

Before:

scopes = 7daee810-3f78-40c4-84c2-7a199428de18/.default openid

After:

scopes = https://energy.azure.com/.default openid

Repeat for config_dev and config_test. Do not update config_prod — production still uses the old scope.

2. Update your Python scripts (interactive auth)

If you use the Python SDK with interactive authentication, update the resource_id:

Before:

resource_id = "7daee810-3f78-40c4-84c2-7a199428de18"
credential = OsduMsalInteractiveCredential(client_id, authority, resource_id)

After:

resource_id = "https://energy.azure.com"
credential = OsduMsalInteractiveCredential(client_id, authority, resource_id)

If you use MSAL directly with interactive flows, update the scopes:

Before:

scopes = ["7daee810-3f78-40c4-84c2-7a199428de18/.default"]

After:

scopes = ["https://energy.azure.com/.default"]
3. Update Postman and other tools

If you use your own Postman setup, Insomnia, or any other tool that obtains tokens using the authorization code flow (grant type authorization_code), update the scope there too:

  • Old scope: 7daee810-3f78-40c4-84c2-7a199428de18/.default (or the equivalent per-instance ID)
  • New scope: https://energy.azure.com/.default

This applies to any tool or workflow where you sign in as a user to get a token.

4. Update your app registration (if you have your own)

If your team has its own app registration that uses the authorization code flow (delegated permissions), you need to update the API permission.

The underlying 1P app is changing from dffa82c7-... to bd0c9d90-89ad-4bb3-97bc-d787b9f69cdc. The new app exposes an access_as_user permission that does not require admin consent — users can consent themselves on first login.

Steps:

  1. Go to your app registration in the Azure Portal → API permissions
  2. Click Add a permission → APIs my organization uses → search for "Azure Data Manager for Energy"
  3. Select the one with client ID bd0c9d90-89ad-4bb3-97bc-d787b9f69cdc (not the old dffa82c7-...)
  4. Choose Delegated permissions → select access_as_user → Add permissions
  5. Remove the old API permission (the per-instance user_impersonation on dffa82c7-...)

No admin consent needed

Unlike the old setup which required admin consent for user_impersonation, the new access_as_user permission can be consented by users themselves. No global admin approval is required.

5. Verify your access

Run a quick health check to confirm everything works:

osdu status

Or via Python:

response = client.get(f"{server}/api/search/v2/health/readiness_check")
print(response.status_code)  # Should be 200

What stays the same

  • Applications and service principals — update to the new unified scope https://energy.azure.com/.default. This works for client credentials as well.
  • Server URLs — no change to base URLs or API paths
  • Data partition IDs — no change
  • Client IDs — no change

Need help?

If you run into issues after updating, contact the OSDU Platform Team:

Last update: 2026-03-02