Verwirrt von Sign-in Flows? Microsoft Entra Authentication Flows vergleichen

Microsoft Entra ID unterstuetzt viele Wege, um Benutzer, Apps, Workloads und Geraete anzumelden.

Nutze diesen Trip als Karte, bevor du einen Flow auswaehlst.

Umfang verstehen

Authentication Flows beantworten unterschiedliche Fragen:

Wer meldet sich an?
Ist ein Benutzer anwesend?
Ist es ein Browser, eine Mobile App, CLI, Backend-Service oder Workload?
Braucht die App nur Sign-in oder auch API-Zugriff?
Kann die Workload Managed Identity oder Federation statt Secret verwenden?

Waehle einen Flow nicht nur, weil er in einer Demo funktioniert. Waehle den Flow, der zum App-Typ und zur Security Boundary passt.

Schnelle Entscheidungstabelle

Szenario	Verwende diesen Flow	Grundidee
Server-side Web App meldet Benutzer an	Authorization Code Flow	Browser erhaelt Code, Backend tauscht ihn gegen Tokens
Single-page App meldet Benutzer an	Authorization Code Flow mit PKCE	Browser erhaelt Code, App tauscht ihn mit PKCE
CLI oder Geraet ohne einfache Browser-Eingabe	Device Code Flow	Benutzer meldet sich auf einem anderen Geraet mit Code an
Backend-Service ruft API als sich selbst auf	Client Credentials Flow	App verwendet eigene Identitaet, keinen Benutzer
Azure Workload ruft Azure Resource auf	Managed Identity	Azure stellt die Workload-Identitaet bereit
GitHub oder Azure DevOps Pipeline ruft Azure auf	Workload Identity Federation	CI/CD tauscht externes Token gegen Entra Token
API ruft andere API fuer angemeldeten Benutzer auf	On-behalf-of Flow	API tauscht eingehendes User Token gegen Downstream API Token
SaaS App braucht Enterprise SSO	SAML oder OIDC	Entra beweist die Benutzeridentitaet gegenueber der SaaS App
Legacy Browser App gibt Tokens direkt zurueck	Implicit oder Hybrid Flow	Token kommt durch den Browser zurueck; fuer neue Apps vermeiden

User Sign-in Flows

Authorization Code Flow

Verwende ihn fuer server-side Web Apps.

Der Browser meldet den Benutzer an, aber die Backend-App erhaelt den Authorization Code und tauscht ihn gegen Tokens.

Benutzer oeffnet App
> App leitet Browser zu Entra um
> Benutzer meldet sich an
> Entra leitet Browser mit Code zurueck
> Backend tauscht Code gegen Tokens
> App erstellt Session

Das ist die normale Wahl fuer klassische Web Apps, weil Tokens auf dem Server bleiben koennen.

Authorization Code Flow mit PKCE

Verwende ihn fuer Single-page Apps, Mobile Apps und Public Clients.

PKCE schuetzt den Code Exchange, wenn die App kein Client Secret sicher speichern kann.

App erstellt Code Verifier und Challenge
> Benutzer meldet sich an
> Entra gibt Code zurueck
> App tauscht Code mit Code Verifier

Das ist der moderne Ersatz fuer Implicit Flow in browserbasierten Apps.

Device Code Flow

Verwende ihn fuer Command-line Tools, Skripte oder Geraete, bei denen Browser Sign-in umstaendlich ist.

CLI zeigt Code
> Benutzer oeffnet Browser auf anderem Geraet
> Benutzer gibt Code ein und meldet sich an
> CLI erhaelt Tokens

Device Code Flow ist user-delegated. Die CLI handelt mit den Berechtigungen des angemeldeten Benutzers.

Implicit und Hybrid Flow

Verwende ihn nur fuer Legacy Apps.

Implicit Flow gibt Tokens direkt durch den Browser zurueck.

response_type=id_token

Hybrid Flow mischt Code Flow mit direkter Token-Rueckgabe.

response_type=code id_token

Fuer neue Apps verwende Authorization Code Flow mit PKCE.

App- und Workload-Flows

Client Credentials Flow

Verwende ihn, wenn ein Backend-Service eine API als sich selbst aufruft.

Es gibt keinen Benutzer.

App authentifiziert sich mit Secret oder Zertifikat
> Entra stellt App-only Token aus
> App ruft API auf

Verwende Zertifikate statt Client Secrets, wenn moeglich. Fuer Azure-gehostete Workloads ist Managed Identity vorzuziehen.

Managed Identity

Verwende sie, wenn eine Azure Resource eine andere Azure-geschuetzte Resource aufrufen muss.

Azure Resource hat Managed Identity
> App fragt Azure nach Token
> kein Secret in Code oder Pipeline gespeichert

Managed Identity ist die sauberste Option fuer Workloads in Azure, weil die Plattform die Credential Rotation uebernimmt.

Workload Identity Federation

Verwende sie, wenn eine externe Workload Azure-Zugriff ohne gespeichertes Secret braucht.

Typische Beispiele:

GitHub Actions
Azure DevOps Pipelines
Kubernetes Workloads

Die externe Plattform stellt ein Token aus. Microsoft Entra vertraut diesem Token und tauscht es gegen ein Entra Access Token.

Pipeline erhaelt externes Token
> Entra validiert Issuer, Subject und Audience
> Entra stellt Access Token aus

Das vermeidet langlebige Client Secrets in CI/CD.

API Delegation Flow

On-Behalf-Of Flow

Verwende ihn, wenn ein Benutzer bei einer API angemeldet ist und diese API eine weitere API als derselbe Benutzer aufrufen muss.

Benutzer meldet sich beim Frontend an
> Frontend ruft API A mit User Token auf
> API A tauscht Token mit On-behalf-of Flow
> API A ruft API B als Benutzer auf

Verwende das fuer delegated API chains. Ersetze es nicht durch App-only Permissions, ausser der Downstream Call soll den Benutzerkontext ignorieren.

Enterprise SSO Optionen

OIDC SSO

OIDC bedeutet OpenID Connect.

Fuer moderne SaaS- und Custom Apps verwendet OIDC normalerweise Authorization Code Flow:

SaaS leitet Benutzer zu Entra um
> Entra gibt Code an SaaS zurueck
> SaaS tauscht Code gegen ID Token
> SaaS meldet Benutzer an

Das ID Token beweist, wer der Benutzer ist.

SAML SSO

SAML ist haeufig bei Enterprise SaaS Applications.

SaaS leitet Benutzer zu Entra um
> Entra authentifiziert Benutzer
> Entra sendet SAML Assertion an SaaS
> SaaS meldet Benutzer an

SAML ist aelter, XML-basiert und fuer Enterprise SSO weiterhin sehr verbreitet.

Tokens, die du sehen wirst

Token oder Wert	Bedeutung
Authorization Code	Temporaerer Wert, der an die Redirect URI zurueckgegeben und gegen Tokens getauscht wird
ID Token	Beweist, wer der angemeldete Benutzer ist
Access Token	Autorisiert Zugriff auf eine API
Refresh Token	Erlaubt einer App, neue Tokens zu holen, ohne den Benutzer erneut anzumelden
Client Secret	Passwortaehnliches Credential fuer eine App; vermeiden, wenn bessere Optionen existieren
Zertifikat	Staerkeres App Credential als ein Secret
Federated Credential	Trust Relationship fuer ein externes Workload Token

Haeufige Fehler

• Client Credentials verwenden, obwohl die App als Benutzer handeln soll
• delegated User Flow verwenden, obwohl kein Benutzer anwesend ist
• Secrets in CI/CD speichern, statt Federation zu verwenden
• Implicit Flow fuer eine neue SPA verwenden
• App Assignment mit API Permissions verwechseln
• denken, dass ein erfolgreicher Sign-in korrekte App-Autorisierung beweist
• breite Graph Permissions anfordern, obwohl nur Sign-in benoetigt wird

Praktische Regel

Beginne mit dem Actor:

Benutzer anwesend? -> Authorization Code, PKCE oder Device Code
Kein Benutzer? -> Client Credentials, Managed Identity oder Workload Federation
API ruft API fuer Benutzer auf? -> On-behalf-of
SaaS SSO? -> OIDC oder SAML
Legacy Browser Token Return? -> Implicit/Hybrid, fuer neue Apps vermeiden

Die meiste Verwirrung verschwindet, sobald du Authentication, Consent, App Assignment und API Authorization trennst.