Client Secret oder Zertifikat? Was du für Entra App Registrations wählen solltest

Jede App Registration, die ohne angemeldeten Benutzer auf Microsoft Graph oder eine andere API zugreift, braucht ein Credential. Entra bietet dafür drei Varianten: Client Secret, Zertifikat und Federated Identity Credential. In der Praxis fällt die Wahl meist auf das Secret, weil es zwei Klicks kostet. Dieser Artikel erklärt, was die Varianten technisch unterscheidet, was Microsoft empfiehlt und wann welche Option angemessen ist.

Client Secret: ein geteiltes Passwort

Ein Client Secret ist eine von Entra erzeugte Zeichenkette mit 16 bis 64 Zeichen. Der Wert wird genau einmal beim Anlegen angezeigt und lässt sich danach nicht mehr auslesen. Die Anwendung speichert ihn im Klartext und schickt ihn bei jedem Token-Abruf als client_secret zusammen mit ihrer Client-ID an den Token-Endpunkt.

Das ist ein geteiltes Geheimnis: Wer den Wert kennt, ist die Anwendung. In Microsoft Graph erscheint das Secret als Eintrag in passwordCredentials mit keyId, displayName, endDateTime und einem hint aus den ersten drei Zeichen.

Zertifikat: ein Schlüsselpaar

Bei einem Zertifikat lädst du nur den öffentlichen Teil (.cer, .pem oder .crt) in die App Registration hoch. Der private Schlüssel bleibt bei der Anwendung, im Zertifikatsspeicher des Servers oder in einem Key Vault. Für den Token-Abruf baut die Anwendung ein kurzlebiges JWT, die Client Assertion, und signiert es mit dem privaten Schlüssel. Im Header steht der SHA-256-Fingerabdruck des Zertifikats (x5t#S256), in den Claims die Client-ID als iss und sub, der Token-Endpunkt als aud und ein Ablaufzeitpunkt. Microsoft dokumentiert PS256 als Signaturalgorithmus und empfiehlt eine Gültigkeit von fünf bis zehn Minuten.

Statt client_secret sendet die Anwendung zwei Parameter: client_assertion_type mit dem festen Wert urn:ietf:params:oauth:client-assertion-type:jwt-bearer und client_assertion mit dem signierten JWT. Entra prüft die Signatur gegen den hochgeladenen öffentlichen Schlüssel. Der private Schlüssel verlässt die Anwendung nie. In Graph liegt das Zertifikat in keyCredentials mit type AsymmetricX509Cert und usage Verify. Entra unterstützt für App-Zertifikate derzeit nur RSA, 2048 Bit sind der empfohlene Standard.

Sicherheitseigenschaften im Vergleich

Der Unterschied liegt nicht in der Kryptografie, sondern darin, was bei einem Leak passiert.

• Ein Client Secret steht im Klartext in einer Konfigurationsdatei, einer Umgebungsvariable, einem Skript oder einer Pipeline-Variable. Jeder dieser Orte landet früher oder später in einem Log, einem Repository oder einem Ticket. Wer den Wert hat, kann sich von überall als die App ausgeben.
• Ein Zertifikat sendet bei jeder Anfrage nur eine Signatur, die wenige Minuten gültig ist. Ein mitgelesener Request nützt einem Angreifer nichts. Angreifbar bleibt der private Schlüssel selbst, also die .pfx-Datei oder der Zertifikatsspeicher. Den kannst du mit Dateisystemrechten, einem nicht exportierbaren Schlüssel oder einem Key Vault schützen.

Was Microsoft empfiehlt

Microsoft ist in den Learn-Artikeln eindeutig: Das Zertifikat ist der empfohlene Credential-Typ. Client Secrets gelten als weniger sicher und sollen in Produktion nicht verwendet werden. Für Tests reicht ein selbstsigniertes Zertifikat, für Produktion empfiehlt Microsoft ein Zertifikat einer bekannten CA und Azure Key Vault für Zugriff und Laufzeit. Der Artikel Migrate applications away from secret-based authentication fasst die Begründung zusammen.

Im Tenant lässt sich das erzwingen. Über App Management Policies kann ein Administrator das Anlegen neuer Secrets blockieren (passwordAddition), die Secret-Laufzeit begrenzen (passwordLifetime) und die Zertifikatslaufzeit begrenzen (asymmetricKeyLifetime). Microsofts eigene Vorgabe im zugehörigen Tutorial: Secrets ganz deaktivieren, Zertifikate auf höchstens 180 Tage begrenzen. Diese Policies setzen eine Premium-Lizenz voraus.

Laufzeiten: beide laufen ab

• Client Secrets bekommen ihre Laufzeit beim Anlegen. Das Portal schlägt 180 Tage vor und erlaubt höchstens 24 Monate. Microsoft empfiehlt weniger als 12 Monate.
• Zertifikate bringen ihre Gültigkeit mit. Wer das Zertifikat ausstellt, legt sie fest: New-SelfSignedCertificate nimmt ohne weitere Angabe ein Jahr, eine interne PKI folgt ihrer Vorlage. Entra übernimmt Start- und Enddatum beim Upload aus dem Zertifikat.

Der verbreitete Satz „Zertifikate laufen länger" stimmt also nur, wenn du sie länger ausstellst. So oder so: Beide Typen haben ein endDateTime, und beide legen die Anwendung still, wenn es erreicht ist.

Zertifikat erstellen und hochladen

Für ein Skript oder einen Dienst auf einem Windows-Server reicht ein selbstsigniertes Zertifikat im lokalen Speicher. Das Beispiel erzeugt eines mit zwei Jahren Gültigkeit und nicht exportierbarem Schlüssel und legt den öffentlichen Teil als .cer-Datei ab:

$cert = New-SelfSignedCertificate -Subject "CN=Backup-Job Kunde A" `
  -CertStoreLocation "Cert:\LocalMachine\My" -KeyExportPolicy NonExportable `
  -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256 `
  -NotAfter (Get-Date).AddYears(2)

Export-Certificate -Cert $cert -FilePath ".\backup-job-kunde-a.cer"

Der Upload läuft im Entra Admin Center: App Registration öffnen, Certificates & secrets, Reiter Certificates, Upload certificate, die .cer-Datei auswählen, Beschreibung eintragen, Add. Danach zeigt Entra Fingerabdruck, Startdatum und Ablaufdatum an. Den Fingerabdruck brauchst du in der Anwendung.

Läuft die Anwendung woanders, etwa in einem Automation Account, erzeugst du das Zertifikat mit exportierbarem Schlüssel, exportierst es per Export-PfxCertificate und importierst die .pfx-Datei dort. In Entra landet weiterhin nur die .cer-Datei. Mit einer internen PKI stellst du das Zertifikat stattdessen dort aus und lädst den öffentlichen Teil genauso hoch.

So authentifiziert sich die Anwendung

Für Microsoft Graph PowerShell genügt ein Parameter mehr beim Verbinden. Das Zertifikat muss dafür unter Cert:\CurrentUser\My oder Cert:\LocalMachine\My liegen:

Connect-MgGraph -ClientId "<app-id>" -TenantId "<tenant-id>" -CertificateThumbprint "<thumbprint>"

In eigenem Code baut MSAL die Assertion selbst: In MSAL.NET ersetzt .WithCertificate(cert) das bisherige .WithClientSecret(secret) am ConfidentialClientApplicationBuilder. Liegt der private Schlüssel in Azure Key Vault, signiert .WithClientAssertion() dort, ohne dass der Schlüssel heruntergeladen wird.

Was Zertifikate im Betrieb kosten

• Verteilung. Der private Schlüssel muss auf jeden Host, auf dem die Anwendung läuft. Bei einem Server ist das ein Import, bei zehn Hosts eine Automatisierung, bei Containern ein Key Vault oder Secret Store.
• Key Vault. Azure Key Vault speichert das Zertifikat, kann es automatisch erneuern und die Assertion signieren, ohne dass der Schlüssel das Vault verlässt.
• Erneuerung. Ein neues Zertifikat hat einen neuen Fingerabdruck. Der muss in Entra hochgeladen und in der Konfiguration ersetzt werden. Der Aufwand ähnelt einem Secret-Tausch, aber oft sind andere Personen beteiligt.
• Mehrere Kunden-Tenants. Derselbe öffentliche Schlüssel lässt sich in beliebig viele App Registrations hochladen. Bequem, aber ein kompromittierter Schlüssel betrifft dann alle Kunden. Ein Zertifikat je Kunde ist sauberer.

Dritte Option: Federated Identity Credentials

Läuft die Anwendung in GitHub Actions, Azure DevOps, Kubernetes, Google Cloud oder unter einer Managed Identity, braucht sie weder Secret noch Zertifikat. Eine Federated Identity Credential unter Certificates & secrets, Reiter Federated credentials, verknüpft die App Registration mit dem Token eines externen Identity Providers. Entra vergleicht issuer, subject und audience des eingehenden Tokens exakt mit dem hinterlegten Eintrag und stellt bei Übereinstimmung ein Access Token aus. Es gibt kein Credential, das abläuft oder leaken kann. Voraussetzung ist ein Identity Provider, der OIDC-Tokens ausstellt. Ein PowerShell-Skript auf einem klassischen Windows-Server hat den nicht.

Entscheidungstabelle

Rotation: mehrere Credentials parallel

passwordCredentials und keyCredentials sind Listen. Eine App Registration kann mehrere Secrets und mehrere Zertifikate gleichzeitig halten. Das erlaubt eine Rotation ohne Ausfall: neues Credential anlegen, Anwendung umstellen, im Sign-in-Log prüfen, dass die neue keyId verwendet wird, dann das alte löschen. Auch der Wechsel von Secret auf Zertifikat funktioniert so: Zertifikat hochladen, App umstellen, Secret löschen. Solange das alte Secret existiert, bleibt es gültig. Der Wechsel ist erst mit dem Löschen abgeschlossen.

Ablauf überwachen

Secret und Zertifikat tragen beide ein endDateTime, und Entra warnt die Anwendung nicht, wenn es erreicht ist. Ein Zertifikat, das nach zwei Jahren ausläuft, legt den Backup-Job genauso still wie ein Secret nach sechs Monaten. Die Ablaufdaten aller App Registrations lassen sich per Graph mit Application.Read.All auslesen, ein Skript dafür steht im Artikel Entra App Registration Secrets laufen ab. Die Entra-Empfehlung „Renew expiring application credentials" (Preview) unter Entra ID, Übersicht, Empfehlungen listet Credentials mit weniger als 30 Tagen Restlaufzeit, aber nur für den geöffneten Tenant und nur, wenn jemand hinsieht. Federated Identity Credentials haben kein Ablaufdatum und fallen aus dieser Überwachung heraus.

Wie SecretExpiry hilft

SecretExpiry liest mit der Berechtigung Application.Read.All die Ablaufdaten von Client Secrets und Zertifikaten aus allen verbundenen Tenants. Das Dashboard zeigt eine Dringlichkeitsliste über alle Kunden. Benachrichtigungen kommen per E-Mail je Ereignis oder als Wochenübersicht, per Teams- oder Slack-Webhook oder als Kalender-Abo (ICS). Je Tenant lässt sich eine eigene Empfängeradresse hinterlegen, einzelne Credentials kannst du stummschalten. Der Dienst kostet ab 10 € pro Tenant und Monat und lässt sich 14 Tage kostenlos testen. Details stehen in der Dokumentation.