Microsoft Entra ID-Authentifizierung mit go-mssqldb

Der Treiber go-mssqldb unterstützt die Microsoft Entra ID-Authentifizierung über das Paketazuread. Dieses Paket registriert einen separaten Treiber namens azuresql, der den Standardtreiber sqlserver mit Unterstützung von Microsoft Entra ID-Anmeldeinformationen kapselt.

Wähle einen Fedauth-Fluss

Verwenden Sie die folgende Tabelle, um den passenden Ablauf für Ihre Hosting-Umgebung und die Quelle der Zugangsdaten auszuwählen:

Wenn du eine Verbindungszeichenfolge zwischen lokaler Entwicklung und Azure-Hosting teilst, ActiveDirectoryDefault ist das ein guter Anfang. Für die Produktion verwenden ActiveDirectoryManagedIdentity oder ActiveDirectoryServicePrincipal um die Latenz der Zugangsdatenkette zu vermeiden.

Installiere das azuread-Paket

Laden Sie das azuread Unterpaket herunter, das den Treiber azuresql registriert:

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

Verwenden Sie den azuresql-treiber

Importiere das azuread Paket (statt oder zusätzlich zum Basispaket go-mssqldb ) und öffne Verbindungen mit dem azuresql Treibernamen:

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")
    // ...
}

Alle folgenden Beispiele zielen auf Azure SQL ab. Behalten Sie encrypt=true&TrustServerCertificate=false in der Verbindungszeichenfolge bei, damit der Treiber das Serverzertifikat überprüft.

Arten von Fedauth-Zertifikaten

Setzen Sie den Verbindungsparameter fedauth auf einen der folgenden Werte. Die meisten Typen werden einer Azure Identity-Anmeldeinformation aus dem Paket azidentity zugeordnet. ActiveDirectoryServicePrincipalAccessToken und benutzerdefinierte Token-Provider-APIs verwenden vom Anrufer bereitgestellte Tokens.

ActiveDirectoryDefault

Verwendet azidentity.DefaultAzureCredential, das die folgenden Zugangsquellen in der Reihenfolge ausprobiert:

1. Umweltvariablen (AZURE_TENANT_ID, AZURE_CLIENT_ID, und so weiter).
2. Workload-Identität für Kubernetes.
3. Verwaltete Identität.
4. Azure CLI-Anmeldeinformationen
5. Azure Developer CLI-Zugangsdaten.

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

Verwenden Sie diesen Typ für die lokale Entwicklung, da er automatisch Azure CLI-Zugangsdaten erkennt. Für den Produktiveinsatz verwenden Sie ActiveDirectoryManagedIdentity oder ActiveDirectoryServicePrincipal direkt. DefaultAzureCredential durchläuft bei der ersten Verbindung jede Quelle für Anmeldeinformationen, was zu zusätzlicher Latenz führt, die für Produktionsworkloads nicht erforderlich ist.

ActiveDirectoryManagedIdentity

Authentifiziert sich mit einer vom System zugewiesenen oder vom Benutzer zugewiesenen verwalteten Identität. Für eine benutzerdefinierte Identität geben Sie die Client-ID im Parameter user id an:

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

Mit einer benutzerdefinierten Identität:

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

ActiveDirectoryServicePrincipal

Authentifiziert sich als Service Principal (App-Registrierung) mit einer Client-ID und einem Client-Geheimnis:

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

Für die zertifikatsbasierte Service-Principal-Authentifizierung verwenden Sie clientcertpath=<path-to-certificate> zusammen mit password=<certificate-password>.

ActiveDirectoryServicePrincipalAccessToken

Verwendet ein vorab erworbenes Service Principal Access Token, das Ihre Anwendung direkt in der Verbindungszeichenfolge weitergibt:

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

Verwenden Sie diesen Fluss nur, wenn Ihre Anwendung bereits den Zugriffstoken außerhalb des Treibers erfasst und aktualisiert hat. Für die meisten Service-to-Service-Szenarien sollten Sie ActiveDirectoryServicePrincipal oder einen benutzerdefinierten Tokenanbieter verwenden.

ActiveDirectoryPassword

Microsoft Entra ID Kennwortauthentifizierung basiert auf der OAuth 2.0 Resource Owner Password Credentials (ROPC)-Erteilung, die es einer Anwendung ermöglicht, sich beim Benutzer direkt anzumelden, indem es sein Kennwort direkt verarbeitet.

Microsoft empfiehlt, den ROPC-Fluss nicht zu verwenden, da er nicht mit MFA kompatibel ist. In den meisten Szenarien sind sicherere Alternativen verfügbar und empfohlen. Dieser Fluss erfordert ein hohes Vertrauen in die Anwendung und trägt Risiken, die in anderen Flüssen nicht vorhanden sind. Verwenden Sie diesen Fluss nur, wenn sicherere Flüsse nicht lebensfähig sind. Microsoft entfernt sich von diesem Authentifizierungsfluss mit hohem Risiko, um Benutzer vor böswilligen Angriffen zu schützen. Weitere Informationen finden Sie unter Planung für die obligatorische mehrstufige Authentifizierung für Azure.

Wenn ein Benutzer bei der Anmeldung vorhanden ist, verwenden Sie die ActiveDirectoryInteractive- oder ActiveDirectoryIntegrated-Authentifizierung, sodass die Attribute des Überwachungspfads für den angemeldeten Benutzer und die Richtlinien für bedingten Zugriff gelten.

Befolgen Sie für unbeaufsichtigte Dienst-zu-Dienst-Szenarien die Microsoft Entra Richtlinien für das Dienstkonto:

• Wenn Ihre Anwendung in Azure Infrastruktur ausgeführt wird, verwenden Sie ActiveDirectoryMSI (oder ActiveDirectoryManagedIdentity in einigen Treibern). Verwaltete Identitäten beseitigen den Aufwand für die Verwaltung und Rotation von Geheimnissen und Zertifikaten.
• Wenn verwaltete Identität nicht verfügbar ist (z. B. wird die Anwendung außerhalb Azure ausgeführt), verwenden Sie ActiveDirectoryServicePrincipal. Wo der Treiber dies unterstützt, bevorzugen Sie ein Clientzertifikat über einen geheimen Clientschlüssel. Bei einem Zertifikat bleibt der private Schlüssel auf dem Client, und nur eine signierte Assertion wird an Microsoft Entra gesendet, um den Client zu authentifizieren. Wenn der Schlüssel in Hardware gespeichert ist (z. B. in einem TPM oder HSM) oder als nicht exportierbar gekennzeichnet ist, kann er nicht wie ein Clientgeheimnis als Zeichenfolge extrahiert werden.
• Verwenden Sie kein Microsoft Entra Benutzerkonto als Dienstkonto.

Authentifiziert sich mit einem Microsoft Entra-Benutzernamen und Passwort:

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

Der Parameter applicationclientid ist für diesen Fluss erforderlich.

ActiveDirectoryInteractive

Öffnet einen browserbasierten interaktiven Anmeldeprompt für den Nutzer. Geeignet für lokale Entwicklungstools:

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

Der Parameter applicationclientid ist für diesen Fluss erforderlich.

ActiveDirectoryDeviceCode

Zeigt einen Gerätecode an, den der Benutzer bei eingeben muss https://microsoft.com/devicelogin. Nützlich für Umgebungen ohne Browser:

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

ActiveDirectoryAzCli

Verwendet das Token aus der angemeldeten Azure CLI-Sitzung:

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

ActiveDirectoryAzureDeveloperCli

Verwendet das Token aus der angemeldeten Azure Developer CLI (azd)-Sitzung:

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

ActiveDirectoryEnvironment

Liest Zugangsdaten aus Umgebungsvariablen aus. Die Azure Identity-Bibliothek inspiziert Variablen wie AZURE_TENANT_ID, AZURE_CLIENT_ID, und AZURE_CLIENT_SECRET:

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

ActiveDirectoryWorkloadIdentity

Authentifiziert sich mithilfe von Workload Identity Federation. Verwenden Sie diese Methode in Kubernetes-Pods mit konfigurierter Azure Workload Identity.

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

ActiveDirectoryAzurePipelines

Authentifiziert sich durch die Verwendung einer Azure Pipelines-Serviceverbindung. Geben Sie die Pipeline-Parameter in der Verbindungszeichenfolge bereit oder lassen Sie den Treiber fehlende Werte aus Azure Pipelines-Umgebungsvariablen lesen.

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

Stellen Sie die Parameter wie vom Treiber gefordert ein:

ActiveDirectoryClientAssertion

Authentifiziert sich durch Verwendung einer Client-Assertion (ein signiertes JWT-Token) statt eines Client-Geheimnisses. Gib das signierte JWT im Parameter clientassertion an:

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

ActiveDirectoryOnBehalfOf

Authentifiziert sich mithilfe des On-Behalf-Of (OBO)-Flows. Der Treiber tauscht ein Upstream-Benutzertoken gegen ein neues Token, das auf SQL Server zugeschnitten ist.

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

Für den Teil der Clientauthentifizierung können password, clientcertpath oder clientassertion verwendet werden, aber userassertion ist immer erforderlich.

ActiveDirectoryIntegrated

Unterstützt einen fortschrittlichen integrierten Authentifizierungs-Workflow. Dieser Modus erfordert eine benutzerdefinierte Token-Erfassungslogik über einen Token-Anbieter.

Verwenden Sie diesen Modus nur unter Windows. Unter Linux und macOS verwenden Sie einen benutzerdefinierten Token-Anbieter für Ihren Authentifizierungsfluss.

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

Custom Token-Anbieter

Wenn keiner der eingebauten fedauth Typen zu Ihrem Szenario passt, verwenden Sie eine dieser Token-Provider-APIs, um Ihre eigene Token-Erwerbslogik bereitzustellen:

NewSecurityTokenConnector (Empfohlen)

Verwenden Sie diese API, wenn Sie ein vorab erworbenes OAuth2-Zugriffstoken haben:

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 (vereinfachte API)

Nutzen Sie diese API für eine einfachere Token-Erfassung ohne Kontextverarbeitung.

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 (benutzerdefinierte ADAL-Workflows)

Nutzen Sie diese API für benutzerdefinierte Azure AD Token-Erwerbungs-Workflows, wenn weder die eingebauten fedauth Modi noch die SecurityToken-APIs zu Ihrem Szenario passen:

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)

Dieser Ansatz ist nützlich, wenn Sie sich mit einem benutzerdefinierten Identitätsanbieter integrieren, Token-Caching implementieren oder einen Credential-Typ verwalten müssen, der nicht vom Paket azuread abgedeckt ist. Die meisten Anwendungen sollten NewSecurityTokenConnector mit einem zuvor abgerufenen Token verwenden.

Gängige Qualifikationsoptionen

Diese Parameter gelten für mehrere Fedauth-Typen:

Verwandte Inhalte

• SQL Server und Windows-Authentifizierung
• Verbindungszeichenfolgen
• Verschlüsselung und Zertifikate