Identity & Security·21. Juli 2026·6 min Lesezeit Client Secret, Certificate oder Federated Login? Der Einsteiger-Guide zu Verbindungen in der Microsoft Cloud
Wer neu in Azure oder der Power Platform ist, trifft schnell auf eine verwirrende Auswahl: Soll sich die App per Client Secret verbinden? Oder doch Certificate? Was ist ein Federated Login, und warum sagen alle, man solle bei neuen Tenants keine Secrets mehr benutzen? Und wieso poppt bei der CLI plötzlich ein Device Code auf?
Die gute Nachricht: Dahinter steckt ein einfaches System. Du musst nur zwei Fragen beantworten — dann fällt die Wahl fast von allein.
Die zwei Grundfragen
- Mensch oder Maschine? Meldet sich eine echte Person an (interaktiv, mit Passwort + MFA), oder läuft ein Dienst ohne Mensch davor — ein Skript, eine Pipeline, ein Backend?
- Wo läuft der Code? In Azure (VM, Function, Container) oder außerhalb (dein Laptop, GitHub Actions, eine andere Cloud, on-prem)?
Diese beiden Achsen bestimmen den Mechanismus. Alles andere sind Details.
Begriffe, die du als Einsteiger kennen musst
- Tenant — deine Microsoft-Entra-ID-Instanz (früher „Azure AD”). Der Namensraum, in dem Nutzer, Apps und Berechtigungen leben.
- App Registration (im Portal „App-Registrierung“) — quasi der Ausweisantrag deiner Anwendung im Tenant. Ergibt eine Client ID (öffentlich, wie ein Benutzername).
- Service Principal — die konkrete Identität der App in deinem Tenant. Die App Registration ist die Vorlage, der Service Principal die Instanz mit Rechten.
- Credential — der Nachweis, dass die App wirklich sie ist: ein Client Secret (Passwort), ein Certificate (Schlüsselpaar) oder eine Federated Credential (Vertrauen zu einem externen Token).
- Access Token — der zeitlich begrenzte „Eintrittsstempel”, den Entra ID ausstellt und mit dem die App auf Ressourcen (z. B. Microsoft Graph, Azure) zugreift.
- Scope / Permission — was die App darf (z. B.
User.Read). Getrennt von der Frage, wie sie sich anmeldet. - Managed Identity — eine von Azure automatisch verwaltete Identität für Code, der in Azure läuft — ganz ohne Credential.
- OIDC (OpenID Connect) — das Standardprotokoll, auf dem Federated Logins aufbauen.
Menschen: interaktiver Login und Device Code
Wenn sich eine echte Person anmeldet, ist der Standard der Authorization Code Flow mit PKCE: Die App schickt dich in den Browser zur Entra-Anmeldeseite, du meldest dich an (inkl. MFA), und die App bekommt am Ende ein Access Token — ohne dein Passwort je zu sehen.
Manchmal gibt es keinen Browser — etwa auf einem Server, in einer SSH-Session oder auf einem Gerät ohne Tastatur. Dafür gibt es den Device Code Flow: Die App zeigt dir einen kurzen Code, du öffnest microsoft.com/devicelogin auf einem beliebigen Gerät, gibst den Code ein und meldest dich dort an.
Faustregel: Mensch + Browser → Authorization Code + PKCE. Mensch + kein Browser → Device Code. Beide sind interaktiv; du gibst nie ein Passwort in die App selbst.
Maschinen: Service Principal mit Secret oder Certificate
Läuft ein Dienst ohne Mensch, meldet er sich als Service Principal über den Client Credentials Flow an. Der Unterschied liegt nur im Credential:
- Client Secret — ein von Entra generiertes Passwort. Einfach einzurichten, aber: Es liegt im Klartext irgendwo (Config, Key Vault, CI-Variable), es läuft ab (maximal 24 Monate, oft kürzer), und wer es kopiert, ist deine App. Der häufigste Ausfall am Freitagabend: ein abgelaufenes Secret.
- Certificate — ein Schlüsselpaar. Die App signiert damit ein kurzlebiges JWT; der private Schlüssel verlässt nie die App, es wird kein Geheimnis übertragen. Sicherer als ein Secret — aber du musst das Zertifikat trotzdem ausrollen und rechtzeitig erneuern.
Federated Login: warum das heute die erste Wahl ist
Secret und Certificate haben dasselbe Grundproblem: Es gibt ein Geheimnis, das du speichern, schützen und rotieren musst — und das leaken oder ablaufen kann.
Workload Identity Federation (die „Federated Credential”) löst das, indem sie gar kein Geheimnis in Entra hinterlegt. Stattdessen vertraut deine App-Registrierung — oder eine User-assigned Managed Identity — den Tokens eines externen Identity Providers: GitHub, ein Kubernetes-Cluster, Google, AWS. Der Workload holt sich dort ein kurzlebiges OIDC-Token und tauscht es bei Entra ID gegen ein Access Token. Entra prüft das Vertrauen anhand von issuer, subject und audience — die müssen exakt matchen.
Der Gewinn laut Microsoft: keine Secrets speichern, nichts rotieren, nichts leakt, nichts läuft ab. Genau deshalb ist Federation für neue Tenants und Szenarien die empfohlene Wahl, wo immer ein OIDC-fähiger Provider vorhanden ist — GitHub Actions, Azure Pipelines, Kubernetes, andere Clouds.
Läuft der Code in Azure? Dann Managed Identity
Wenn dein Code innerhalb von Azure läuft — VM, App Service, Function, Container — brauchst du meist gar keine App Registration: Eine Managed Identity gibt der Ressource eine Identität, und die Azure-Plattform verwaltet die Credential komplett. Kein Secret, kein Zertifikat, nichts im Code.
Faustregel: Code in Azure → Managed Identity. Code außerhalb, aber OIDC-Provider da → Federated. Sonst → Certificate. Secret nur, wenn nichts anderes geht.
Die Entscheidungsmatrix
| Szenario | Empfehlung | Warum |
|---|---|---|
| Person meldet sich an, Browser vorhanden | Authorization Code + PKCE | Standard, sicher, MFA-fähig |
| Person, aber kein Browser (Server / CLI) | Device Code Flow | Anmeldung am Zweitgerät |
| Code läuft in Azure (VM / Function / Container) | Managed Identity | Azure verwaltet alles, kein Geheimnis |
| GitHub Actions / Azure Pipelines / Kubernetes / andere Cloud | Federated Credential | Kein Secret, OIDC-Vertrauen |
| Dienst außerhalb, kein OIDC-Provider | Certificate | Schlüssel bleibt lokal |
| Schnelltest / Legacy, nichts anderes möglich | Client Secret | Einfach, aber läuft ab & leakt leicht |
Grenzen und Ehrliches
- Federated braucht einen OIDC-Provider. Ein simples on-prem-Skript ohne Identity Provider kann sich nicht föderieren — dort bleibt Certificate die beste Option.
- Entra-eigene Tokens gehen nicht. Für den Federated-Flow darfst du keine von Entra ID selbst ausgestellten Tokens verwenden — nur die eines externen IdP.
- issuer / subject / audience matchen case-sensitiv. Der häufigste Federation-Fehler ist ein Tippfehler im subject — etwa der falsche GitHub-Branch oder Environment-Name.
- Client Secret ist nicht „böse”. Für einen schnellen Test völlig okay. Nur nichts, worauf man produktiv baut.
Fazit: der Merksatz für Einsteiger
Zwei Fragen, fertig:
- Mensch? → interaktiv (Browser: Authorization Code + PKCE, sonst Device Code).
- Maschine? → in Azure: Managed Identity · außerhalb mit OIDC: Federated · sonst: Certificate · Secret nur im Notfall.
Wer neu anfängt, richtet am besten von Beginn an Federation bzw. Managed Identity ein — dann gibt es nie ein Geheimnis, das man vergisst zu rotieren, und keinen Freitagabend-Ausfall wegen eines abgelaufenen Secrets.