Skip to main content

Authorization

Follow this guide to create a new Azure Table Storage credential that will allow Nexla to authenticate to and exchange data with your Azure Table Storage account.
azure_table_storage_api_auth.png

Azure Table Storage

Prerequisites​

The Azure Table Storage connector authenticates to the Table service (data plane) using Microsoft Entra ID OAuth 2.0 with the authorization-code (3-legged) flow. Access tokens are issued by the Microsoft identity platform and presented to https://{account}.table.core.windows.net as Authorization: Bearer headers, alongside an x-ms-version request header.

Before creating a credential in Nexla, complete the following one-time setup in Microsoft Entra ID and Azure.

Register a Microsoft Entra ID Application​

The Microsoft Entra app registration represents Nexla as an OAuth 2.0 confidential client and supplies the Client ID, Client Secret, and authorization endpoints used during the consent flow.

  1. Sign in to the Microsoft Entra admin center with an account that has permission to manage application registrations in your tenant.

  2. In the left navigation, expand Identity > Applications, and select App registrations.

  3. Click + New registration at the top of the App registrations page.

  4. On the Register an application page, enter the following:

    • Name: A descriptive name for the application, for example Nexla – Azure Table Storage.

    • Supported account types: Select the option that matches your access needs. Choose Accounts in this organizational directory only (Single tenant) for an app limited to your tenant, or Accounts in any organizational directory (Multitenant) if Nexla will authenticate users from other tenants.

    • Redirect URI: Set Platform to Web, and enter the Nexla OAuth callback URL shown in the Nexla credential overlay. The redirect URI registered with Microsoft Entra ID must match this value exactly.

  5. Click Register to create the application.

  6. After registration, copy the Application (client) ID value from the application's Overview page. This is the Client ID that will be entered into the Nexla credential.

    Also note the Directory (tenant) ID on the Overview page. For single-tenant applications, you will substitute this tenant ID in place of common in the authorization and token URLs entered into Nexla.

Create a Client Secret​

The client secret authenticates Nexla to the Microsoft identity platform when exchanging the authorization code for an access token.

  1. From the application's left navigation, select Manage > Certificates & secrets.

  2. On the Client secrets tab, click + New client secret.

  3. Enter a description for the secret (for example, Nexla integration secret), select an expiration period that matches your organization's rotation policy, and click Add.

  4. Immediately copy the Value of the new secret and store it in a secure secret manager. The secret value is shown only once; after you leave the page, only the secret ID is visible.

Important

The Client Secret Value grants Microsoft Entra ID token-issuance rights for this application. Store it in a secure secret manager, never commit it to source control, and rotate it immediately if it is exposed.

Grant the Azure Storage API Permission​

The application must be granted the user_impersonation delegated permission on the Azure Storage resource so that issued tokens are accepted by https://{account}.table.core.windows.net.

  1. From the application's left navigation, select Manage > API permissions.

  2. Click + Add a permission, select the Microsoft APIs tab (or APIs my organization uses if Azure Storage is not listed), and choose Azure Storage.

  3. Select Delegated permissions, check the user_impersonation scope, and click Add permissions.

  4. If your tenant requires admin consent for delegated permissions, click Grant admin consent for {tenant} to consent on behalf of all users. Otherwise, individual users will be prompted for consent the first time they authorize the application.

Assign an Azure RBAC Role to the User on the Storage Account​

Microsoft Entra ID authorization for Azure Table Storage requires that the authorizing user (or group) hold a data-plane RBAC role on the target storage account. Without an RBAC assignment, the API returns 403 AuthorizationPermissionMismatch even when the access token is otherwise valid.

  1. In the Azure portal, navigate to Storage accounts, and open the target storage account.

  2. From the left navigation, select Access control (IAM).

  3. Click + Add > Add role assignment.

  4. On the Role tab, search for one of the following roles and select it based on the access needed:

    • Storage Table Data Reader: Read-only access to tables and entities. Use this role when Nexla will only ingest data from Azure Table Storage.

    • Storage Table Data Contributor: Read, write, and delete access to tables and entities. Use this role when Nexla will write, update, upsert, or delete entities.

  5. On the Members tab, select User, group, or service principal, click + Select members, and add the user account that will authorize the Nexla credential.

  6. Click Review + assign to apply the role.

    RBAC role assignments can take several minutes to propagate before the assigned user can call the Table service with a Microsoft Entra ID bearer token.

Identify the Storage Account Name and API Version​

  1. From the storage account's Overview page in the Azure portal, note the Storage account name (lowercase letters and numbers, 3–24 characters). This value is the hostname prefix of {account}.table.core.windows.net.

  2. Confirm that the Azure Storage service version supports Microsoft Entra ID bearer-token authentication for the Table service. The Table service requires x-ms-version of 2020-12-06 or later to accept OAuth 2.0 bearer tokens.

For complete information about Microsoft Entra ID authorization for Azure Storage, see the Authorize with Microsoft Entra ID (Azure Storage REST API) documentation. For details on the OAuth 2.0 authorization-code flow, see the Microsoft identity platform OAuth 2.0 authorization-code flow documentation. For Azure Storage service-version details, see Versioning for Azure Storage.

Create an Azure Table Storage Credential​

  • To create a new Azure Table Storage credential, after selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.

Credential Name & Description​

  1. Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.

    Resource descriptions are recommended but are not required. They should be used to provide information about the resource purpose, data freshness, etc. that can help the owner and other users efficiently understand and utilize the resource.

OAuth 2.0 Configuration​

  1. Enter the Microsoft Entra ID v2.0 authorization endpoint in the Authorization URL field. The default is https://login.microsoftonline.com/common/oauth2/v2.0/authorize. For a single-tenant application, replace common with the Directory (tenant) ID captured during app registration (for example, https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/oauth2/v2.0/authorize).

  2. Enter the Application (client) ID from the Microsoft Entra app registration in the Client ID field. This value is shown on the application's Overview page in the Microsoft Entra admin center.

  3. Confirm the Access Scope field contains the Azure Storage delegated scope. The default value is https://storage.azure.com/user_impersonation offline_access:

    • https://storage.azure.com/user_impersonation requests delegated access to Azure Storage on behalf of the signed-in user.

    • offline_access requests a refresh token so Nexla can refresh expired access tokens without prompting the user again.

  4. Enter the Microsoft Entra ID v2.0 token endpoint in the Token URL field. The default is https://login.microsoftonline.com/common/oauth2/v2.0/token. For a single-tenant application, replace common with the Directory (tenant) ID, matching the value used in the Authorization URL field.

  5. Enter the Client Secret Value copied from the Certificates & secrets page of the Microsoft Entra app registration in the Client Secret field. Nexla stores this value securely and uses it only during token exchange.

Azure Storage Settings​

  1. Enter the Azure Storage Storage Account Name in the Storage Account Name field. This must match the hostname prefix of {account}.table.core.windows.net (lowercase letters and numbers, 3–24 characters).

  2. Enter the Azure Storage service version in the API Version (x-ms-version) field. The default value 2020-12-06 is the minimum version that supports Microsoft Entra ID bearer-token authentication for the Table service. Set a later version only if a specific Table service feature requires it.

    The configured API Version (x-ms-version) is sent on every Table service request as the x-ms-version header. Versions earlier than 2020-12-06 do not accept OAuth 2.0 bearer tokens for the Table service and will cause authentication errors.

Authorize the Credential​

  1. Click Authorize to launch the Microsoft Entra ID consent screen in a new browser tab. Sign in with the user account that holds the Azure RBAC role (Storage Table Data Reader or Storage Table Data Contributor) on the target storage account, and approve the requested permissions.

  2. After consent is granted, Microsoft Entra ID redirects back to Nexla with an authorization code. Nexla automatically exchanges this code for an access token and refresh token, and stores the resulting tokens on the credential. Nexla refreshes the access token automatically using the refresh token when it expires.

Save the Credential​

  1. Once all of the relevant steps in the above sections have been completed, click the Save button at the bottom of the overlay to save the configured credential.

  2. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation and can be selected for use with a new data source or destination.