Authentification Microsoft Entra ID avec go-mssqldb

Le pilote go-mssqldb prend en charge l’authentification Microsoft Entra ID via le package azuread. Ce package enregistre un pilote distinct nommé azuresql qui enveloppe le pilote standard sqlserver avec le support des identifiants Microsoft Entra ID.

Attention

Toutes les méthodes d’authentification fedauth intégrées nécessitent le nom du azuresql pilote (non sqlserver). Si vous utilisez sql.Open("sqlserver", ...) avec un fedauth paramètre, l’authentification échoue silencieusement avec Login failed for user ''. Importez le azuread paquet et utilisez-le azuresql comme montré dans l’exemple suivant.

Choisissez un flux FedAuth

Utilisez le tableau suivant pour choisir le flux approprié pour votre environnement d’hébergement et la source de vos accréditations :

Si tu as besoin de te connecter depuis...	Commencez par...	À utiliser quand...
Développement local	`ActiveDirectoryDefault`	Vous souhaitez réutiliser les identifiants Azure CLI ou Azure Developer sans configurer localement un principal de service ou une identité managée.
Une application hébergée sur Azure avec une identité gérée	`ActiveDirectoryManagedIdentity`	Vous voulez une configuration de production prévisible et vous ne voulez pas d’autres sources locales de crédibilité dans la chaîne.
Un pipeline CI/CD dans Azure DevOps	`ActiveDirectoryAzurePipelines`	Votre pipeline utilise déjà une connexion de service Azure et expose `SYSTEM_ACCESSTOKEN`.
Kubernetes avec Azure Workload Identity	`ActiveDirectoryWorkloadIdentity`	Votre pod reçoit un fichier de jeton OIDC et vous souhaitez utiliser une identité de charge de travail plutôt qu’un secret client.
Un principal de service avec un secret ou un certificat	`ActiveDirectoryServicePrincipal`	Votre application s’authentifie avec un enregistrement d’application et vous gérez le secret client ou le certificat.
Un outil qui possède déjà un jeton d’accès	`ActiveDirectoryServicePrincipalAccessToken` ou un fournisseur de jetons personnalisés	Votre application acquiert et actualise les jetons en dehors du pilote.
Un jeton utilisateur délégué provenant d’une API web en amont	`ActiveDirectoryOnBehalfOf`	Vous devez échanger un token utilisateur contre un token à portée SQL dans un service de niveau intermédiaire.
Un outil de développement ou un utilitaire interactif	`ActiveDirectoryInteractive`, `ActiveDirectoryDeviceCode`, `ActiveDirectoryAzCli`, ou `ActiveDirectoryAzureDeveloperCli`	Une personne est présente pour se connecter, ou vous souhaitez réutiliser une session locale de la CLI existante.
Une application Windows uniquement qui gère les exigences d’authentification intégrée	`ActiveDirectoryIntegrated` (avancé)	Vous fournissez une logique d’acquisition de jetons personnalisée pour les scénarios intégrés.

Si vous partagez une chaîne de connexion entre le développement local et l’hébergement Azure, ActiveDirectoryDefault c’est un bon point de départ. En production, utilisez ActiveDirectoryManagedIdentity ou ActiveDirectoryServicePrincipal pour éviter la latence de la chaîne d’identifiants.

Installez le package azuread

Téléchargez le azuread sous-paquet, qui enregistre le pilote azuresql :

go get github.com/microsoft/go-mssqldb/azuread

Utilisez le pilote azuresql

Importez le paquet azuread (à la place du paquet go-mssqldb de base ou en complément de celui-ci) et ouvrez des connexions à l’aide du nom de pilote azuresql :

import (
    "database/sql"

    _ "github.com/microsoft/go-mssqldb/azuread"
)

func main() {
    db, err := sql.Open("azuresql",
        "sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryDefault&encrypt=true&TrustServerCertificate=false")
    // ...
}

Tous les exemples suivants visent Azure SQL. Conservez encrypt=true&TrustServerCertificate=false dans la chaîne de connexion afin que le pilote valide le certificat du serveur.

Types de titres Fedauth

Réglez le fedauth paramètre de connexion sur l’une des valeurs suivantes. La plupart des types sont associés à des informations d’identification Azure Identity du package azidentity. ActiveDirectoryServicePrincipalAccessToken et les API personnalisées des fournisseurs de jetons utilisent des jetons fournis par l’appelant.

ActiveDirectoryDefault

Utilise azidentity.DefaultAzureCredential, qui essaie les sources de qualification suivantes dans l’ordre :

Variables d’environnement (AZURE_TENANT_ID, AZURE_CLIENT_ID, etc.).
Identité des charges de travail pour Kubernetes.
Identité managée.
Informations d’identification Azure CLI.
Informations d’identification d’Azure Developer CLI.

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryDefault&encrypt=true&TrustServerCertificate=false

Utilisez ce type pour le développement local car il détecte automatiquement les identifiants Azure CLI. En production, utilisez directement ActiveDirectoryManagedIdentity ou ActiveDirectoryServicePrincipal. DefaultAzureCredential Parcourt chaque source d’identifiants lors de la première connexion, ce qui ajoute une latence dont les charges de travail en production n’ont pas besoin.

ActiveDirectoryManagedIdentity

S’authentifie avec une identité gérée attribuée par le système ou l’utilisateur. Pour une identité attribuée par l’utilisateur, indiquez l’identifiant client dans le user id paramètre :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryManagedIdentity&encrypt=true&TrustServerCertificate=false

Avec une identité attribuée par l’utilisateur :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryManagedIdentity&user id=<client-id>&encrypt=true&TrustServerCertificate=false

Note

ActiveDirectoryMSI est un alias pour ActiveDirectoryManagedIdentity.

ActiveDirectoryServicePrincipal

Authentifie en tant que principal de service (enregistrement d’application) avec un identifiant client et un secret client :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryServicePrincipal&user id=<client-id>&password=<client-secret>&encrypt=true&TrustServerCertificate=false

Pour l’authentification du principal de service basée sur le certificat, utilisez clientcertpath=<path-to-certificate> avec password=<certificate-password>.

Note

ActiveDirectoryApplication est un alias pour ActiveDirectoryServicePrincipal.

ActiveDirectoryServicePrincipalAccessToken

Utilise un token d’accès principal de service préacquis que votre application transmet directement dans la chaîne de connexion :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryServicePrincipalAccessToken&password=<access-token>&encrypt=true&TrustServerCertificate=false

Utilisez ce flux uniquement lorsque votre application acquiert et actualise déjà le jeton d’accès en dehors du pilote. Pour la plupart des scénarios service-to-service, préférez ActiveDirectoryServicePrincipal ou un fournisseur de jetons personnalisés.

Mot de passe Active Directory

Important

L’option d’authentification ActiveDirectoryPassword (authentification par mot de passe de Microsoft Entra ID) est dépréciée dans les pilotes Microsoft SQL. Ce flux d’authentification à haut risque est incompatible avec l’authentification multifacteur obligatoire Microsoft Entra (MFA) et peut ne pas fonctionner dans les locataires où l’authentification multifacteur est appliquée. Prévoyez de migrer vers une autre méthode d’authentification Microsoft Entra.

Microsoft Entra ID l’authentification par mot de passe est basée sur l’octroi ROPC (Resource Owner Password Credentials) OAuth 2.0, qui permet à une application de se connecter à l’utilisateur en gérant directement son mot de passe.

Microsoft recommande de ne pas utiliser le flux ROPC, car il n'est pas compatible avec l'authentification multifacteur. Dans la plupart des scénarios, des alternatives plus sécurisées sont disponibles et recommandées. Ce flux nécessite un degré élevé de confiance dans l’application et comporte des risques qui ne sont pas présents dans d’autres flux. Utilisez ce flux uniquement lorsque les flux plus sécurisés ne sont pas viables. Microsoft s’éloigne de ce flux d’authentification à haut risque pour protéger les utilisateurs contre les attaques malveillantes. Pour plus d’informations, consultez Planification de l’authentification multifacteur obligatoire pour Azure.

Lorsqu’un utilisateur est présent lors de la connexion, utilisez l’authentification ActiveDirectoryInteractive ou ActiveDirectoryIntegrated afin que les attributs de piste d’audit de l’utilisateur connecté et des stratégies d’accès conditionnel s’appliquent.

Pour les scénarios de service à service non supervisés, suivez les recommandations relatives aux comptes de service Microsoft Entra :

Si votre application s’exécute sur Azure infrastructure, utilisez ActiveDirectoryMSI (ou ActiveDirectoryManagedIdentity dans certains pilotes). Les identités managées éliminent la surcharge liée à la maintenance et à la rotation des secrets et des certificats.
Si l'identité managée n'est pas disponible (par exemple, l'application s'exécute en dehors de Azure), utilisez ActiveDirectoryServicePrincipal. Si le pilote le prend en charge, préférez un certificat client plutôt qu’un secret client. Avec un certificat, la clé privée reste sur le client et seule une assertion signée est envoyée à Microsoft Entra pour authentifier le client. Si la clé est stockée sur un support matériel (tel qu’un TPM ou un HSM) ou marquée comme non exportable, elle ne peut pas être extraite sous forme de chaîne, comme on peut le faire avec un secret client.
N'utilisez pas de compte d'utilisateur Microsoft Entra en tant que compte de service.

Authentification avec un nom d’utilisateur et un mot de passe Microsoft Entra :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryPassword&user id=<user>@mydomain.com&password=<password>&applicationclientid=<app-id>&encrypt=true&TrustServerCertificate=false

Le applicationclientid paramètre est requis pour ce flux.

ActiveDirectoryInteractive

Ouvre une invite interactive de connexion basée sur le navigateur pour l’utilisateur. Adapté aux outils de développement local :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryInteractive&user id=<user>@mydomain.com&applicationclientid=<app-id>&encrypt=true&TrustServerCertificate=false

Le applicationclientid paramètre est requis pour ce flux.

ActiveDirectoryDeviceCode

Affiche un code de périphérique que l’utilisateur peut saisir à .https://microsoft.com/devicelogin Utile pour les environnements sans navigateur :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryDeviceCode&encrypt=true&TrustServerCertificate=false

ActiveDirectoryAzCli

Utilise le jeton de la session Azure CLI connectée :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryAzCli&encrypt=true&TrustServerCertificate=false

ActiveDirectoryAzureDeveloperCli

Utilise le jeton de la session Azure Developer CLI (azd) connectée :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryAzureDeveloperCli&encrypt=true&TrustServerCertificate=false

Environnement Active Directory

Lit les identifiants à partir des variables d’environnement. La bibliothèque d’identité Azure inspecte des variables telles que AZURE_TENANT_ID, AZURE_CLIENT_ID, et AZURE_CLIENT_SECRET:

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryEnvironment&encrypt=true&TrustServerCertificate=false

ActiveDirectoryWorkloadIdentity

S’authentifie à l’aide de la fédération d’identités de charge de travail. Utilisez cette méthode dans les pods Kubernetes avec l’identité de charge de travail Azure configurée.

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryWorkloadIdentity&encrypt=true&TrustServerCertificate=false

ActiveDirectoryAzurePipelines

Authentifie en utilisant une connexion de service Azure Pipelines. Fournissez les paramètres du pipeline dans la chaîne de connexion, ou laissez le pilote lire les valeurs manquantes des variables d’environnement Azure Pipelines.

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryAzurePipelines&user id=<client-id>@<tenant-id>&serviceconnectionid=<service-connection-id>&systemtoken=<system-access-token>&encrypt=true&TrustServerCertificate=false

Définissez les paramètres exigés par le pilote :

Paramètre	Description
`user id`	ID client principal de service, optionnellement suivi de `@tenant-id`.
`serviceconnectionid`	ID de la connexion de service d’Azure DevOps.
`systemtoken`	Le jeton d’accès du système pipeline (`$(System.AccessToken)`).

ActiveDirectoryClientAssertion

Authentifie en utilisant une assertion client (un jeton JWT signé) au lieu d’un secret client. Fournissez le JWT signé dans le clientassertion paramètre :

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryClientAssertion&user id=<client-id>@<tenant-id>&clientassertion=<jwt-token>&encrypt=true&TrustServerCertificate=false

ActiveDirectoryOnBehalfOf

Authentifie en utilisant le flux On-Behalf-Of (OBO). Le pilote échange un jeton utilisateur provenant de l’amont contre un nouveau jeton limité à SQL Server.

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryOnBehalfOf&user id=<client-id>@<tenant-id>&password=<client-secret>&userassertion=<user-token>&encrypt=true&TrustServerCertificate=false

La phase d’authentification client peut utiliser password, clientcertpath, ou clientassertion, mais userassertion est toujours requise.

Intégré à Active Directory

Prend en charge un flux d’authentification intégrée avancé. Ce mode nécessite une logique d’acquisition de jetons personnalisée via un fournisseur de jetons.

Utilisez ce mode uniquement sous Windows. Sous Linux et macOS, utilisez un fournisseur de jetons personnalisé pour votre flux d’authentification.

sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryIntegrated&encrypt=true&TrustServerCertificate=false

Fournisseur de jetons personnalisés

Si aucun des types intégrés fedauth ne correspond à votre scénario, utilisez l’une de ces API de fournisseurs de jetons pour fournir votre propre logique d’acquisition de jetons :

NewSecurityTokenConnector (recommandé)

Utilisez cette API lorsque vous avez un jeton d’accès OAuth2 préacquis :

import (
    "context"
    "database/sql"
    "log"

    "github.com/microsoft/go-mssqldb"
)

connector, err := mssql.NewSecurityTokenConnector(
    "sqlserver://<server>.database.windows.net?database=AdventureWorks2025&encrypt=true&TrustServerCertificate=false",
    func(ctx context.Context) (string, error) {
        // Return a pre-acquired OAuth2 access token.
        return myTokenProvider(ctx)
    },
)
if err != nil {
    log.Fatal(err)
}
db := sql.OpenDB(connector)

NewAccessTokenConnector (API simplifiée)

Utilisez cette API pour une acquisition de tokens plus simple sans gestion du contexte.

import (
    "database/sql"
    "log"

    "github.com/microsoft/go-mssqldb"
)

connector, err := mssql.NewAccessTokenConnector(
    "sqlserver://<server>.database.windows.net?database=AdventureWorks2025&encrypt=true&TrustServerCertificate=false",
    func() (string, error) {
        // Return a pre-acquired OAuth2 access token.
        return mySimpleTokenProvider()
    },
)
if err != nil {
    log.Fatal(err)
}
db := sql.OpenDB(connector)

NewActiveDirectoryTokenConnector (flux de travail ADAL personnalisés)

Utilisez cette API pour des flux de travail personnalisés d’acquisition de jetons Azure AD lorsque ni les modes intégrés fedauth ni les API SecurityToken ne correspondent à votre scénario :

import (
    "context"
    "database/sql"
    "log"

    "github.com/microsoft/go-mssqldb"
)

connector, err := mssql.NewActiveDirectoryTokenConnector(
    "sqlserver://<server>.database.windows.net?database=AdventureWorks2025&encrypt=true&TrustServerCertificate=false",
    mssql.FedAuthADALWorkflowPassword,
    func(ctx context.Context, serverSPN, stsURL string) (string, error) {
        // Custom ADAL workflow using server-provided SPN and STS URL.
        return myCustomADALFlow(ctx, serverSPN, stsURL)
    },
)
if err != nil {
    log.Fatal(err)
}
db := sql.OpenDB(connector)

Cette approche est utile lorsque vous devez intégrer avec un fournisseur d’identité personnalisé, implémenter la mise en cache de jetons ou gérer un type de crédent non couvert par le azuread package. La plupart des applications doivent utiliser NewSecurityTokenConnector avec un jeton obtenu au préalable.

Options de certification commune

Ces paramètres s’appliquent à plusieurs types de fedauth :

Paramètre	Description
`applicationclientid`	ID de l’application client. Requise pour `ActiveDirectoryPassword` et `ActiveDirectoryInteractive`.
`clientcertpath`	Chemin d’accès à un fichier de certificat client PEM ou PFX pour l’authentification d’un principal de service basée sur un certificat ou l’authentification On-Behalf-Of.
`clientassertion`	Assertion JWT signée pour `ActiveDirectoryClientAssertion` ou pour l’authentification On-Behalf-Of.
`serviceconnectionid`	ID de la connexion de service Azure Pipelines.
`systemtoken`	Jeton d’accès système d’Azure Pipelines.
`userassertion`	Jeton utilisateur en amont pour `ActiveDirectoryOnBehalfOf`.
`tokenfilepath`	Chemin vers le fichier de jetons OIDC pour `ActiveDirectoryWorkloadIdentity` dans Kubernetes.
`additionallyallowedtenants`	Liste des identifiants de locataire supplémentaires séparés par virgules à autoriser lorsque l’authentification multi-locataire est nécessaire.
`disableinstancediscovery`	Réglez pour `true` désactiver la découverte d’instance ; utilisez seulement si vous contrôlez l’URL d’autorité.
`sendcertificatechain`	Définissez sur `true` pour envoyer la chaîne de certificats pour l’authentification basée sur les certificats.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-07-21