Authentication¶

The dbt-fabric-samdebruyn adapter supports a variety of authentication methods so you can connect to Microsoft Fabric from any environment. This guide walks through each method, explains when to use it, and provides ready-to-use profiles.yml examples.

All examples below assume the following base profile structure. Only the authentication-related keys change per method.

default:
  target: dev
  outputs:
    dev:
      type: fabric
      workspace: My Workspace
      database: my_data_warehouse
      schema: dbt
      # + authentication keys shown below

client_secret: "{{ env_var('AZURE_CLIENT_SECRET') }}"

Local development¶

Azure CLI¶

The simplest way to authenticate during local development. Log in once with the Azure CLI and dbt will reuse that session.

Step 1 — Log in

az login

Your account does not need access to any Azure subscription — it only needs access to your Fabric workspace.

Step 2 — Configure your profile

default:
  target: dev
  outputs:
    dev:
      type: fabric
      database: my_data_warehouse
      schema: dbt
      workspace: My Workspace  # or use host
      authentication: CLI

The Azure CLI itself supports multiple login methods (browser, device code, service principal, managed identity, …), making this a flexible option that adapts to many scenarios.

Automatic (DefaultAzureCredential)¶

Set authentication to auto (or omit it entirely — it's the default). The adapter uses the Azure Identity SDK's DefaultAzureCredential which tries several credential sources in order:

1. Environment variables
2. Workload identity
3. Managed identity
4. Azure CLI
5. Azure PowerShell
6. Azure Developer CLI
7. Interactive browser (if available)

default:
  target: dev
  outputs:
    dev:
      type: fabric
      database: my_data_warehouse
      schema: dbt
      workspace: My Workspace
      # authentication: auto  ← this is the default, can be omitted

This means that if you are logged in with Azure PowerShell (Connect-AzAccount), it will automatically be picked up — no extra configuration needed.

CI/CD & automated environments¶

Service Principal¶

Use a Microsoft Entra ID app registration (service principal) with a client secret. This is ideal for unattended, automated runs.

Prerequisites:

• A registered application in Microsoft Entra ID
• The application must have access to your Fabric workspace
• You need the client ID, client secret, and tenant ID

default:
  target: ci
  outputs:
    ci:
      type: fabric
      database: my_data_warehouse
      schema: dbt
      workspace: My Workspace
      authentication: ActiveDirectoryServicePrincipal
      tenant_id: "{{ env_var('AZURE_TENANT_ID') }}"
      client_id: "{{ env_var('AZURE_CLIENT_ID') }}"
      client_secret: "{{ env_var('AZURE_CLIENT_SECRET') }}"

Environment variables¶

Set authentication to environment and configure credentials through environment variables. The adapter uses Azure Identity's EnvironmentCredential, which supports the following variables:

default:
  target: ci
  outputs:
    ci:
      type: fabric
      database: my_data_warehouse
      schema: dbt
      workspace: My Workspace
      authentication: environment

This method keeps your profiles.yml completely free of secrets, which is an advantage over the explicit ActiveDirectoryServicePrincipal method.

Workload Identity (federated credentials)¶

Use workload_identity to authenticate with Workload Identity Federation — no client secret needed. The adapter uses ClientAssertionCredential under the hood, fetching a fresh federated token on each Azure token refresh.

This works with any identity provider that issues OIDC tokens: GitHub Actions, Kubernetes, or any custom OIDC endpoint.

Prerequisites:

• A registered application in Microsoft Entra ID with a federated credential configured for your identity provider
• The application must have access to your Fabric workspace
• You need the client ID and tenant ID (no client secret)

default:
  target: ci
  outputs:
    ci:
      type: fabric
      database: my_data_warehouse
      schema: dbt
      workspace: My Workspace
      authentication: workload_identity
      tenant_id: "{{ env_var('AZURE_TENANT_ID') }}"
      client_id: "{{ env_var('AZURE_CLIENT_ID') }}"
      federated_token_url: "{{ env_var('ACTIONS_ID_TOKEN_REQUEST_URL') }}&audience=api://AzureADTokenExchange"
      federated_token_header: "bearer {{ env_var('ACTIONS_ID_TOKEN_REQUEST_TOKEN') }}"

default:
  target: ci
  outputs:
    ci:
      type: fabric
      database: my_data_warehouse
      schema: dbt
      workspace: My Workspace
      authentication: workload_identity
      tenant_id: "{{ env_var('AZURE_TENANT_ID') }}"
      client_id: "{{ env_var('AZURE_CLIENT_ID') }}"
      federated_token_file: /var/run/secrets/azure/tokens/azure-identity-token

Fabric Notebook¶

When running dbt inside a Fabric Notebook, the recommended approach is to use environment variable or service principal authentication.

Configure your notebook to set the required environment variables (e.g. AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET) and use the environment or ActiveDirectoryServicePrincipal method.

default:
  target: notebook
  outputs:
    notebook:
      type: fabric
      database: my_data_warehouse
      schema: dbt
      workspace: My Workspace
      authentication: environment

Alternatively, with explicit service principal configuration:

default:
  target: notebook
  outputs:
    notebook:
      type: fabric
      database: my_data_warehouse
      schema: dbt
      workspace: My Workspace
      authentication: ActiveDirectoryServicePrincipal
      tenant_id: "{{ env_var('AZURE_TENANT_ID') }}"
      client_id: "{{ env_var('AZURE_CLIENT_ID') }}"
      client_secret: "{{ env_var('AZURE_CLIENT_SECRET') }}"

Custom token credential¶

Bring your own TokenCredential¶

If the built-in authentication methods don't cover your scenario, you can supply any class that implements the azure.core.credentials.TokenCredential protocol. The adapter loads the class by its dotted import path at runtime and calls get_token() whenever it needs an access token.

This is useful when:

• Your organization uses a custom OAuth flow or token broker
• You need Workload Identity Federation with a non-standard setup
• A desktop tool already has its own credential and you want to pass it through
• You want to wrap an existing credential with custom logging or caching

Step 1 -- Implement a TokenCredential

Your class must implement the get_token method from the azure.core.credentials.TokenCredential protocol:

# my_pkg/auth.py
from azure.core.credentials import AccessToken, TokenCredential


class MyCredential(TokenCredential):
    def __init__(self, token_url: str, **kwargs):
        self.token_url = token_url

    def get_token(self, *scopes, **kwargs) -> AccessToken:
        # Your custom logic to acquire a token
        ...

Step 2 -- Configure your profile

default:
  target: dev
  outputs:
    dev:
      type: fabric
      database: my_data_warehouse
      schema: dbt
      workspace: My Workspace
      authentication: token_credential
      credential_class: "my_pkg.auth.MyCredential"
      credential_kwargs:
        token_url: "{{ env_var('TOKEN_URL') }}"

The credential_class must be a fully qualified dotted path to an importable Python class. The credential_kwargs dictionary is passed as keyword arguments to the class constructor.

Other methods¶

The adapter supports several additional authentication methods such as managed identity, interactive browser, and pre-acquired access tokens. For a complete list of all supported methods and their configuration options, see the configuration documentation.

Troubleshooting¶

Which authentication method is being used?¶

Run dbt debug to see the resolved connection information, including the active authentication method.

dbt debug

Common issues¶