Azure Blob Storage Credentials

Create Azure credentials securely for Azure Blob Storage Datasources.

Use this page when you want Roboflow to mirror an Azure Blob Storage container through Datasources.

For Azure Blob Storage, use Datasources and Bucket Mirror whenever you want ongoing sync, repeat imports, or metadata sidecar support. Do not build a signed URL or local download workflow for that use case.

Azure names a container inside a storage account, so a Datasource needs both. Roboflow reads the container only, and never writes to it.

Choose a Credential Type

Roboflow supports three Azure access patterns for Blob Storage Datasources:

1. Workload Identity: recommended: no keys, nothing to rotate

2. Container SAS: quickest to create, but expires and must be replaced

3. Service Principal: a client secret, for tenants that block federated credentials

Workload Identity is keyless: no secret is ever created, stored, or rotated. Microsoft recommends it for workloads outside Azure, so prefer it unless your tenant policy blocks federated credentials.

Security Guidelines

Before you create any credential:

1. Use a dedicated app registration for Roboflow.

2. Grant only Storage Blob Data Reader, scoped to the specific container rather than the storage account.

3. Prefer Workload Identity over a SAS or a client secret, because both of those expire quietly and stop mirroring.

4. Store credentials only in Roboflow Workspace Credentials or your own secret manager.

5. You can revoke Roboflow's access at any time by removing the role assignment, deleting the federated credential, or revoking the SAS.

Microsoft Entra matches a federated credential on issuer, subject, and audience, exactly and case-sensitively. It accepts values that do not match and then fails sign-in without reporting an error, so copy the values from the Create Credential modal rather than retyping them.

Use Workload Identity Federation

Recommended. No keys are exchanged. Roboflow presents a Google-issued token, which Entra exchanges for a short-lived access token scoped to your container. Roboflow stores no secret and you have nothing to rotate or renew. Entra stores only the federated credential you configure below.

1. In Roboflow, open Add an Azure (Workload Identity) credential. The modal shows an Issuer, a Subject identifier, and an Audience. Keep it open, you will need all three.

   The Audience is unique to your Workspace. It is what binds the grant to you, so another Workspace pointing at the same app registration is rejected by Entra.

2. Create an app registration, or reuse one you keep for Roboflow:

   • Open App registrations → New registration → name it → Register.

   • Copy the Directory (tenant) ID and Application (client) ID from the Overview page.

   Prefer the CLI? The second command creates the service principal that the role assignment in step 4 is made against.

   az ad app create --display-name roboflow-datasource
   az ad sp create --id YOUR_APP_CLIENT_ID

3. Add a federated credential to that app registration:

   • Open your app registration → Certificates & secrets → Federated credentials → Add credential.

   • Federated credential scenario = Other issuer.

   • Enter the three values from the Roboflow modal: Issuer, Subject identifier, and Audience.

   • Give it a name, then Add.

   Prefer the CLI? Substitute the values from the modal:

   az ad app federated-credential create --id YOUR_APP_OBJECT_ID --parameters '{
     "name": "roboflow-datasource",
     "issuer": "https://accounts.google.com",
     "subject": "SUBJECT_FROM_MODAL",
     "audiences": ["AUDIENCE_FROM_MODAL"]
   }'

   An app registration supports at most 20 federated credentials.

4. Assign the app registration read access to your container:

   • Open Storage accounts → your account → Containers → your container → Access Control (IAM) → Add → Add role assignment.

   • Role = Storage Blob Data Reader, Members = your app registration → Review + assign.

   Prefer the CLI?

   az role assignment create \
     --assignee YOUR_APP_CLIENT_ID \
     --role "Storage Blob Data Reader" \
     --scope "/subscriptions/SUB_ID/resourceGroups/RG/providers/Microsoft.Storage/storageAccounts/ACCOUNT/blobServices/default/containers/CONTAINER"

5. Back in the modal, enter the tenant ID and client ID and save. The Audience is filled in for you. Continue with Create the Credential in Roboflow.

Role assignments can take a few minutes to take effect. If Datasource validation fails immediately after you assign the role, wait and validate again.

Use a Container SAS Token

Quickest to create, but it expires. A shared access signature needs no Entra setup at all. Mirroring stops when the SAS expires, and you have to issue a new one, so prefer Workload Identity for anything long-lived.

1. Generate a container SAS with Read and List permissions:

   • Open Storage accounts → your account → Containers → your container → Shared access tokens.

   • Permissions = Read and List. Set an expiry that suits your rotation schedule.

   • Click Generate SAS token and URL and copy either the token or the full URL.

   Prefer the CLI? This signs the SAS with your storage account key, the same way the portal does. The key stays on your machine and is never sent to Roboflow.

   az storage container generate-sas \
     --account-name YOUR_ACCOUNT \
     --account-key YOUR_ACCOUNT_KEY \
     --name YOUR_CONTAINER \
     --permissions rl \
     --expiry 2027-01-01T00:00Z \
     --output tsv

   To sign with your Entra identity instead, drop --account-key and add --auth-mode login --as-user. That needs the Storage Blob Delegator role on the storage account, and Azure caps the expiry at seven days.

2. In Roboflow, open Add an Azure (SAS Token) credential, paste the token, and save. Pasting the full SAS URL works too: Roboflow keeps only the query string.

Roboflow reads the signed expiry from the token, so Datasource validation tells you the date a SAS expired instead of reporting a generic access error. A SAS is a bearer token: anyone who holds it gets the same read access until it expires or you revoke it. Nothing ties it to your Workspace the way the audience ties a federated credential, so there is no per-Workspace value to configure.

Use a Service Principal

Use only if your tenant blocks federated credentials. A client secret expires and must be rotated, which is the failure mode Workload Identity avoids.

1. Create an app registration and copy its Directory (tenant) ID and Application (client) ID, as in step 2 of Workload Identity.

2. Create a client secret:

   • Open your app registration → Certificates & secrets → Client secrets → New client secret.

   • Set a description and expiry, then Add, and copy the Value immediately. Azure shows it only once.

   Prefer the CLI?

   az ad app credential reset --id YOUR_APP_OBJECT_ID --append

3. Assign Storage Blob Data Reader on the container, as in step 4 of Workload Identity.

4. In Roboflow, open Add an Azure (Service Principal) credential, enter the tenant ID, client ID, and secret, and save.

Set a calendar reminder before the secret expires. Mirroring stops when it does.

Create the Credential in Roboflow

After you set up the Azure-side access:

1. Go to Credentials in Workspace settings.

2. Click Add Credential (or use a type-specific link: Workload Identity, SAS Token, Service Principal).

3. Choose the Azure credential type you set up.

4. Enter the tenant ID and client ID (Workload Identity), the SAS token (Container SAS), or the tenant ID, client ID, and secret (Service Principal).

5. Save the credential.

6. Select that credential when you create the Datasource.

When you create the Datasource, paste the full container URL (https://ACCOUNT.blob.core.windows.net/CONTAINER) into the container field. Roboflow fills in the storage account for you. A bare container name works too, as long as you enter the storage account yourself.

Next Step

After the credential is saved, continue with Datasources to configure bucket mirroring.