# Authentifizierungsprotokolle Authentication Protocols

OAuth 2.0, OpenID Connect, SAML 2.0, WS-Federation, Token-Typen, Claims und moderne vs. Legacy-Authentifizierung im Überblick. OAuth 2.0, OpenID Connect, SAML 2.0, WS-Federation, token types, claims, and modern vs. legacy authentication at a glance.

OAuth 2.0 / OIDC OAuth 2.0 / OIDC

Modernes Autorisierungs- und Identitätsprotokoll für Web-, Mobile- und API-Szenarien.Modern authorization and identity protocol for web, mobile, and API scenarios.

SAML 2.0 SAML 2.0

XML-basiertes Föderationsprotokoll für Enterprise SSO mit älteren Anwendungen.XML-based federation protocol for enterprise SSO with legacy applications.

WS-Federation WS-Federation

Älteres Microsoft/ADFS-Protokoll; weiterhin für viele on-premises Apps relevant.Older Microsoft/ADFS protocol; still relevant for many on-premises apps.

Token-Typen Token types

ID Token, Access Token, Refresh Token – jeder mit unterschiedlichem Zweck und Lebensdauer.ID token, access token, refresh token – each with different purpose and lifetime.

## Überblick Overview

Microsoft Entra ID unterstützt eine Vielzahl von Authentifizierungs- und Autorisierungsprotokollen. Moderne Applikationen sollten OAuth 2.0 mit OpenID Connect nutzen, da diese Protokolle auf MFA, Conditional Access und moderne Token-Verwaltung ausgelegt sind. Legacy-Protokolle wie NTLM, Kerberos (nur on-prem), SMTP AUTH oder IMAP umgehen Conditional Access und sollten blockiert werden. Microsoft Entra ID supports a wide range of authentication and authorization protocols. Modern applications should use OAuth 2.0 with OpenID Connect since these protocols are designed for MFA, Conditional Access, and modern token management. Legacy protocols like NTLM, Kerberos (on-prem only), SMTP AUTH, or IMAP bypass Conditional Access and should be blocked.

⚠️ Legacy-Authentifizierung blockieren⚠️ Block legacy authentication

Anmeldungen über Legacy-Auth-Protokolle (SMTP AUTH, POP, IMAP, Basic Auth gegen Exchange oder SharePoint) können nicht durch MFA oder Conditional Access geschützt werden. Erstellen Sie eine CA-Policy, die alle Legacy-Clients blockiert, bevor Sie Security Defaults deaktivieren. Sign-ins via legacy auth protocols (SMTP AUTH, POP, IMAP, Basic Auth against Exchange or SharePoint) cannot be protected by MFA or Conditional Access. Create a CA policy that blocks all legacy clients before disabling Security Defaults.

## OAuth 2.0 – Grundprinzip OAuth 2.0 – Core principle

OAuth 2.0 ist ein Autorisierungsframework, das einer Anwendung (Client) erlaubt, im Namen eines Benutzers oder als eigene Identität auf geschützte Ressourcen zuzugreifen, ohne das Passwort des Benutzers zu kennen. Entra ID ist dabei der Authorization Server. OAuth 2.0 is an authorization framework that allows an application (client) to access protected resources on behalf of a user or as its own identity, without knowing the user's password. Entra ID acts as the Authorization Server.

Rolle Role | Entra ID-Entsprechung Entra ID equivalent | Aufgabe Task
--- | --- | ---
Resource Owner Resource Owner | Benutzer oder Service User or service | Gibt Zugriff auf eigene Ressourcen frei Grants access to own resources
Client Client | App-Registrierung / Service Principal App registration / Service Principal | Fordert Token an, greift auf Ressource zu Requests tokens, accesses resource
Authorization Server Authorization Server | Microsoft Entra ID Microsoft Entra ID | Authentifiziert, prüft CA, stellt Token aus Authenticates, checks CA, issues tokens
Resource Server Resource Server | Microsoft Graph, eigene API, Azure Resource Microsoft Graph, own API, Azure resource | Nimmt Access Token entgegen, prüft Ansprüche Accepts access token, validates claims

## OAuth 2.0 Grant Types (Flows)OAuth 2.0 Grant types (flows)

Flow Flow | Einsatz Use case | Sicherheit Security
--- | --- | ---
Authorization Code + PKCE Authorization Code + PKCE | Öffentliche Clients (SPA, Mobile, Desktop)Public clients (SPA, mobile, desktop) | Empfohlen; PKCE verhindert Code Injection Recommended; PKCE prevents code injection
Authorization Code (confidential)Authorization Code (confidential) | Web-Apps mit Back-End-Server Web apps with back-end server | Client Secret oder Certificate sichert den Tausch Client secret or certificate secures the exchange
Client Credentials Client Credentials | Daemon-Apps, Background Services, no user Daemon apps, background services, no user | Certificate bevorzugen gegenüber Client Secret Prefer certificate over client secret
On-Behalf-Of (OBO)On-Behalf-Of (OBO) | Middle-Tier-APIs, die im Benutzerkontext weiteragieren Middle-tier APIs acting in user context | Delegiertes Zugriffstoken mit Benutzercontext Delegated access token preserving user context
Device Code Device Code | Geräte ohne Browser (IoT, Headless CLI)Devices without browser (IoT, headless CLI) | Benutzer autorisiert auf separatem Gerät User authorizes on a separate device
Implicit (Legacy)Implicit (Legacy) | Veraltet; früher für SPAs Deprecated; formerly used for SPAs | Nicht mehr empfohlen; durch Auth Code + PKCE ersetzen No longer recommended; replace with Auth Code + PKCE
Resource Owner Password Credentials (ROPC)Resource Owner Password Credentials (ROPC) | Nur absoluter Notfall (Migration, Legacy)Absolute emergency only (migration, legacy) | Kein MFA, kein CA – stark risikoreich No MFA, no CA – highly risky

### Authorization Code Flow mit PKCE – Schrittübersicht Authorization Code Flow with PKCE – step overview

PKCE (Proof Key for Code Exchange) ist ein Erweiterungsmechanismus für den Authorization Code Flow, der für öffentliche Clients (kein sicheres Client Secret möglich) obligatorisch sein sollte. PKCE (Proof Key for Code Exchange) is an extension mechanism for the Authorization Code Flow that should be mandatory for public clients (no secure client secret possible).

## | Schritt Step | Akteur Actor | Beschreibung Description
--- | --- | --- | ---
1 1 | Code Verifier / Challenge erzeugen Code Verifier / Challenge erzeugen | Client Client | Zufälliger Code Verifier; SHA-256 als Code Challenge Random code verifier; SHA-256 as code challenge
2 2 | Authorization Request Authorization Request | Client → Entra ID Client → Entra ID | Redirect zur /authorize-Endpoint mit code_challenge Redirect to /authorize endpoint with code_challenge
3 3 | Authentifizierung + CA Authentifizierung + CA | Benutzer + Entra ID Benutzer + Entra ID | Benutzer meldet sich an, CA-Policies werden ausgewertet User signs in, CA policies are evaluated
4 4 | Authorization Code Authorization Code | Entra ID → Client Entra ID → Client | Kurzlebiger Code per Redirect URI an Client Short-lived code via redirect URI to client
5 5 | Token Request Token Request | Client → Entra ID Client → Entra ID | Code + code_verifier gegen Tokens tauschen Exchange code + code_verifier for tokens
6 6 | Tokens empfangen Tokens empfangen | Client Client | ID Token, Access Token, Refresh Token ID token, access token, refresh token

HTTP – Authorization Request

    GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
    ?client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    &response_type=code
    &redirect_uri=https%3A%2F%2Fapp.contoso.com%2Fcallback
    &scope=openid%20profile%20email%20https%3A%2F%2Fgraph.microsoft.com%2FUser.Read
    &state=12345
    &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
    &code_challenge_method=S256

HTTP – Token Request

    POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
    Content-Type: application/x-www-form-urlencoded

    client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    &grant_type=authorization_code
    &code=OAAABAAAAiL...
    &redirect_uri=https%3A%2F%2Fapp.contoso.com%2Fcallback
    &code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

## OpenID Connect (OIDC)OpenID Connect (OIDC)

OpenID Connect ist eine Identitätsschicht auf OAuth 2.0. Es fügt das ID Token hinzu, das den authentifizierten Benutzer beschreibt. OIDC ist der empfohlene Standard für modernes Single Sign-On. OpenID Connect is an identity layer on top of OAuth 2.0. It adds the ID Token describing the authenticated user. OIDC is the recommended standard for modern Single Sign-On.

OIDC Endpoint OIDC Endpoint | Zweck Purpose | URL-Muster URL-Muster
--- | --- | ---
Authorization Authorization | Benutzeranmeldung einleiten Initiate user sign-in | `/{tenant}/oauth2/v2.0/authorize`
Token Token | Token anfordern Request tokens | `/{tenant}/oauth2/v2.0/token`
UserInfo UserInfo | Benutzerprofilinfos abrufen Retrieve user profile info | `/oidc/userinfo`
Logout Logout | Session beenden End session | `/{tenant}/oauth2/v2.0/logout`
Discovery (JWKS)Discovery (JWKS) | Public Keys für Token-Validierung Public keys for token validation | `/{tenant}/discovery/v2.0/keys`
OpenID Configuration OpenID Configuration | Metadata-Dokument Metadata document | `/{tenant}/.well-known/openid-configuration`

### Standard-Scopes (OIDC)Standard scopes (OIDC)

Scope Scope | Claims im ID Token Claims in ID token
--- | ---
openid openid | sub, iss, aud, exp, iat, tid sub, iss, aud, exp, iat, tid
profile profile | name, family_name, given_name, preferred_username, oid name, family_name, given_name, preferred_username, oid
email email | email, email_verified email, email_verified
address address | Adressclaims (selten genutzt in Entra)Address claims (rarely used in Entra)
offline_access offline_access | Kein Claim, aber Refresh Token im Response No claim, but refresh token in response

## Token-Typen Token types

Token Token | Format Format | Zweck Purpose | Lebensdauer (Standard)Lifetime (default)
--- | --- | --- | ---
ID Token ID Token | JWT (signed)JWT (signed) | Wer ist der Benutzer? (Identitätsnachweis für die App)Who is the user? (identity proof for the app) | 1 Stunde / 1 hour 1 Stunde / 1 hour
Access Token Access Token | JWT (signed/opaque)JWT (signed/opaque) | Autorisierung gegenüber einer API/Ressource Authorization to an API/resource | 1 Stunde / 1 hour 1 Stunde / 1 hour
Refresh Token Refresh Token | Opaque (nicht lesbar)Opaque (not readable) | Neue Access Tokens anfordern ohne Re-Authentifizierung Request new access tokens without re-authentication | 24h (SFT) / 90 Tage rolling 24h (SFT) / 90 Tage rolling
Primary Refresh Token (PRT)Primary Refresh Token (PRT) | Opaque, gerätegebunden Opaque, device-bound | SSO auf verwalteten Windows-Geräten SSO on managed Windows devices | 14 Tage rolling 14 Tage rolling

### Wichtige Claims im Access Token Key claims in access token

Claim Claim | Bedeutung Meaning | Beispielwert Example value
--- | --- | ---
iss iss | Aussteller (Entra Tenant)Issuer (Entra tenant) | https://login.microsoftonline.com/{tid}/v2.0 https://login.microsoftonline.com/{tid}/v2.0
aud aud | Zielressource (Client-ID oder App-URI)Target resource (client ID or app URI) | api://myapi oder 00000003-0000-0000-c000-000000000000 api://myapi oder 00000003-0000-0000-c000-000000000000
oid oid | Benutzer-Objekt-ID in Entra User object ID in Entra | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
scp scp | Delegierte Scopes (user context)Delegated scopes (user context) | User.Read Mail.Send User.Read Mail.Send
roles roles | App-Roles (app context)App roles (app context) | Reports.Read.All DataExporter Reports.Read.All DataExporter
tid tid | Tenant-ID Tenant ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
upn upn | UserPrincipalName des Benutzers UserPrincipalName of the user | user@contoso.com user@contoso.com
exp exp | Ablaufzeit (Unix epoch)Expiry time (Unix epoch) | 1700000000 1700000000
amr amr | Authentication Method Reference Authentication Method Reference | ["pwd","mfa","ngcmfa"]["pwd","mfa","ngcmfa"]
acr acr | Authentication Context Class Reference Authentication Context Class Reference | c1 (mit Step-Up-Auth)c1 (mit Step-Up-Auth)

## SAML 2.0 SAML 2.0

SAML 2.0 (Security Assertion Markup Language) ist ein XML-basiertes Protokoll für die Föderierung von Identitäten zwischen Identity Provider (IdP) und Service Provider (SP). Entra ID kann sowohl als IdP als auch als SP fungieren. SAML 2.0 (Security Assertion Markup Language) is an XML-based protocol for federating identities between an Identity Provider (IdP) and a Service Provider (SP). Entra ID can act as both IdP and SP.

Entra als Entra as | Szenario Scenario | Konfiguration Configuration
--- | --- | ---
Identity Provider (IdP)Identity Provider (IdP) | SSO für SAML-fähige Enterprise Apps (z. B. Salesforce, ServiceNow)SSO for SAML-capable enterprise apps (e.g. Salesforce, ServiceNow) | Enterprise App → SAML SSO → SP-Metadaten importieren Enterprise App → SAML SSO → import SP metadata
Service Provider (SP)Service Provider (SP) | Föderierung mit externem IdP (ADFS, Ping, Okta)Federation with external IdP (ADFS, Ping, Okta) | Direct Federation oder SAML IdP in External Identities Direct Federation or SAML IdP in External Identities

### SAML Assertion-Struktur assertion structure

XML – Vereinfachte SAML Response Simplified SAML response

    <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
        Destination="https://app.contoso.com/acs">
      <saml:Issuer>https://sts.windows.net/{tenant-id}/</saml:Issuer>
      <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
      <saml:Assertion>
        <saml:Subject>
          <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
            user@contoso.com
          </saml:NameID>
        </saml:Subject>
        <saml:AttributeStatement>
          <saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
            <saml:AttributeValue>user@contoso.com</saml:AttributeValue>
          </saml:Attribute>
        </saml:AttributeStatement>
      </saml:Assertion>
    </samlp:Response>

SAML-Claim SAML claim | Entra-Quelle Entra source
--- | ---
NameID (emailAddress)NameID (emailAddress) | user.mail oder user.userprincipalname user.mail oder user.userprincipalname
givenname givenname | user.givenname user.givenname
surname surname | user.surname user.surname
groups groups | Gruppenobjekt-IDs oder sAMAccountName (konfigurierbar)Group object IDs or sAMAccountName (configurable)
roles roles | App-Rollen der Enterprise App App roles of the Enterprise App

## WS-Federation WS-Federation

WS-Federation ist ein älteres Microsoft-Protokoll, das hauptsächlich von ADFS und Windows-basierten Applikationen genutzt wird. Entra ID unterstützt WS-Fed für Enterprise SSO-Szenarien, insbesondere bei der Migration von ADFS. WS-Federation is an older Microsoft protocol mainly used by ADFS and Windows-based applications. Entra ID supports WS-Fed for enterprise SSO scenarios, especially during ADFS migration.

Endpunkt Endpoint | URL URL
--- | ---
WS-Fed Sign-On WS-Fed Sign-On | https://login.microsoftonline.com/{tenant}/wsfed https://login.microsoftonline.com/{tenant}/wsfed
WS-Fed Metadata WS-Fed Metadata | https://login.microsoftonline.com/{tenant}/federationmetadata/2007-06/federationmetadata.xml https://login.microsoftonline.com/{tenant}/federationmetadata/2007-06/federationmetadata.xml

## Legacy-Authentifizierung Legacy authentication

Legacy-Protokolle wie SMTP AUTH, POP, IMAP, Basic Auth und NTLM können keine modernen Sicherheitskontrollen (MFA, CA) nutzen. Sie stellen ein erhöhtes Angriffsziel (Password Spray, Brute Force) dar. Legacy protocols like SMTP AUTH, POP, IMAP, Basic Auth, and NTLM cannot use modern security controls (MFA, CA). They present an elevated attack target (password spray, brute force).

Protokoll Protocol | CA-Bedingung in Entra CA condition in Entra | Empfehlung Recommendation
--- | --- | ---
SMTP AUTH SMTP AUTH | Other clients Other clients | Blockieren; OAuth2 für SMTP nutzen Block; use OAuth2 for SMTP
IMAP / POP IMAP / POP | Other clients Other clients | Blockieren; moderne Mail-Clients erzwingen Block; enforce modern mail clients
Exchange ActiveSync (EAS)Exchange ActiveSync (EAS) | Exchange ActiveSync Exchange ActiveSync | Separate Policy mit App-Protection-Anforderung Separate policy with app protection requirement
Basic Auth REST Basic Auth REST | Other clients Other clients | Vollständig deaktiviert in Exchange Online seit 2022 Fully disabled in Exchange Online since 2022
NTLM (on-prem)NTLM (on-prem) | Kein Entra-Signal No Entra signal | Entra Private Access für moderne Ablösung Entra Private Access for modern replacement

PowerShell – Legacy-Auth-Nutzung analysieren Analyze legacy auth usage

    Connect-MgGraph -Scopes "AuditLog.Read.All"
    $legacyClients = @("Exchange ActiveSync","IMAP","POP","SMTP","Authenticated SMTP","Other clients")
    $since = (Get-Date).AddDays(-30).ToString("o")
    $logs = Get-MgAuditLogSignIn -Filter "createdDateTime ge $since" -All |
        Where-Object { $_.ClientAppUsed -in $legacyClients }
    $logs | Group-Object UserPrincipalName, ClientAppUsed |
        Select-Object Count, Name | Sort-Object Count -Descending

## Claims-Transformationen Claims transformations

Für SAML und OIDC können Claims per Claim Mapping Policy oder über optionale Claims angepasst werden. Dies ist wichtig, wenn Anwendungen bestimmte Attributnamen oder -formate erwarten. For SAML and OIDC, claims can be customized via Claim Mapping Policy or optional claims. This is important when applications expect specific attribute names or formats.

JSON – Optionale Claims in App-Manifest Optional claims in app manifest

    {
      "optionalClaims": {
        "idToken": [
          { "name": "upn", "essential": false },
          { "name": "email", "essential": false },
          { "name": "family_name", "essential": false }
        ],
        "accessToken": [
          { "name": "groups", "essential": false, "additionalProperties": ["sam_account_name"] },
          { "name": "wids", "essential": false }
        ],
        "saml2Token": [
          { "name": "upn", "essential": false }
        ]
      }
    }

## Continuous Access Evaluation (CAE)Continuous Access Evaluation (CAE)

CAE ermöglicht es Entra ID, Access Tokens vorzeitig zu widerrufen, ohne auf den normalen Token-Ablauf warten zu müssen. Ressourcenserver (Exchange Online, SharePoint, Teams, Microsoft Graph) registrieren sich als CAE-fähig und erhalten Push-Benachrichtigungen bei kritischen Ereignissen. CAE enables Entra ID to revoke access tokens prematurely without waiting for the normal token expiry. Resource servers (Exchange Online, SharePoint, Teams, Microsoft Graph) register as CAE-capable and receive push notifications on critical events.

Auslösendes Ereignis Triggering event | Verhalten Behavior
--- | ---
Benutzer deaktiviert User disabled | Token sofort widerrufen Token revoked immediately
Passwort geändert/zurückgesetzt Password changed/reset | Token innerhalb von Minuten widerrufen Token revoked within minutes
Hohes Benutzerrisiko High user risk | CA-Richtlinien erneut erzwungen CA policies re-enforced
IP-Standortänderung (Netzwerkbedingung)IP location change (network condition) | Neues Token außerhalb des Named Location erfordert Re-Auth New token outside named location requires re-auth

✅ Empfehlung✅ Recommendation

CAE ist für Microsoft 365-Ressourcen standardmäßig aktiviert. Aktivieren Sie CAE für eigene APIs durch Überprüfung des `xms_cc`-Claims im Access Token und Implementierung des 401 + WWW-Authenticate-Challenge-Musters. CAE is enabled by default for Microsoft 365 resources. Enable CAE for your own APIs by checking the `xms_cc` claim in the access token and implementing the 401 + WWW-Authenticate challenge pattern.

## Token-Lifetime-Konfiguration Token lifetime configuration

Die Lebensdauer von Tokens kann über Token Lifetime Policies angepasst werden. Für moderne Apps empfiehlt Microsoft, die Standard-Lebensdauern beizubehalten und stattdessen Session Controls in CA zu nutzen. Token Lifetime Policies sind primär für SAML-Szenarien oder spezielle Legacy-Anforderungen relevant. The lifetime of tokens can be customized via Token Lifetime Policies. For modern apps Microsoft recommends keeping the default lifetimes and instead using Session Controls in CA. Token Lifetime Policies are primarily relevant for SAML scenarios or special legacy requirements.

PowerShell – Token Lifetime Policy erstellen Create Token Lifetime Policy

    Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration"

    $policyDef = @{
        definition = @(
            '{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"01:00:00","MaxInactiveTime":"30.00:00:00","MaxAgeSingleFactor":"until-revoked","MaxAgeMultiFactor":"until-revoked"}}'
        )
        displayName = "Custom Token Lifetime"
        isOrganizationDefault = $false
    }

    $policy = New-MgPolicyTokenLifetimePolicy -BodyParameter $policyDef

    # Policy einer App-Registrierung zuweisen
    New-MgApplicationTokenLifetimePolicyByRef -ApplicationId "<appObjectId>" `
        -OdataId "https://graph.microsoft.com/v1.0/policies/tokenLifetimePolicies/$($policy.Id)"

## SAML-Debugging SAML debugging

Für die Fehlersuche in SAML-Szenarien sind der SAML Token Decoder (browser-seitig) und das Entra-Anmeldeprotokoll die wichtigsten Werkzeuge. Die häufigsten SAML-Fehler sind ungültige Reply URLs, fehlende Claims und Zertifikatsablauf. For troubleshooting SAML scenarios, the SAML token decoder (browser-side) and the Entra sign-in log are the most important tools. The most common SAML errors are invalid reply URLs, missing claims, and certificate expiry.

Fehler Error | Ursache Cause | Lösung Solution
--- | --- | ---
AADSTS50105 AADSTS50105 | Benutzer nicht der Enterprise App zugewiesen User not assigned to the Enterprise App | User Assignment aktivieren und Benutzer/Gruppe zuweisen Enable user assignment and assign user/group
AADSTS75011 AADSTS75011 | Authentifizierungsmethode stimmt nicht überein Authentication method mismatch | RequestedAuthnContext in SAML-Anfrage prüfen Check RequestedAuthnContext in SAML request
AADSTS650056 AADSTS650056 | Fehlende Admin Consent für benötigte Scopes Missing admin consent for required scopes | Admin Consent im Enterprise App Grant erteilen Grant admin consent in Enterprise App grant
Zertifikat abgelaufen Zertifikat abgelaufen | SAML-Signaturzertifikat der Enterprise App abgelaufen SAML signing certificate of the Enterprise App expired | Neues Zertifikat generieren und SP-Seite aktualisieren Generate new certificate and update SP side

## Workload-Identitäten und Protokolle Workload identities and protocols

Workload-Identitäten (Service Principals, Managed Identities) nutzen ausschließlich den Client Credentials Flow oder Federated Identity Credentials. Für maximale Sicherheit sollten Zertifikate statt Client Secrets und Federated Identity Credentials (Workload Identity Federation) verwendet werden. Workload identities (service principals, managed identities) exclusively use the Client Credentials Flow or Federated Identity Credentials. For maximum security, certificates instead of client secrets and Federated Identity Credentials (Workload Identity Federation) should be used.

Methode Method | Sicherheit Security | Einsatz Use case
--- | --- | ---
Client Secret Client Secret | Niedrig – gespeichert, rotierbar Low – stored, rotatable | Nur für Tests; niemals in Produktion Tests only; never production
Certificate Certificate | Hoch – privater Schlüssel nie übertragen High – private key never transmitted | Produktive Service-Accounts Production service accounts
Federated Identity (OIDC)Federated Identity (OIDC) | Sehr hoch – kein gespeichertes Geheimnis Very high – no stored secret | GitHub Actions, Azure DevOps, Kubernetes GitHub Actions, Azure DevOps, Kubernetes
Managed Identity Managed Identity | Sehr hoch – keine Anmeldedatenverwaltung Very high – no credential management | Azure-gehostete Workloads Azure-hosted workloads

## Token-Validierung Token validation

Ressourcenserver müssen eingegangene Access Tokens validieren. Die Validierung umfasst die Signaturprüfung (JWKS), Aussteller-Überprüfung, Zielgruppen-Check (`aud`-Claim) und Ablaufzeit-Validierung. Resource servers must validate incoming access tokens. Validation includes signature verification (JWKS), issuer check, audience check (`aud` claim), and expiry validation.

Validierungsschritt Validation step | Beschreibung Description | Claim / Endpunkt Claim / endpoint
--- | --- | ---
Signatur Signature | RS256-Signatur gegen JWKS-URI prüfen Verify RS256 signature against JWKS URI | jwks_uri aus OpenID Configuration jwks_uri aus OpenID Configuration
Aussteller Issuer | `iss`-Claim mit Tenant-ID oder Common-Issuer vergleichen Compare `iss` claim with tenant ID or common issuer | iss iss
Zielgruppe Audience | `aud`-Claim muss App-ID der eigenen Ressource enthalten `aud` claim must contain the app ID of the resource | aud aud
Ablaufzeit Expiry | `exp`-Claim darf nicht in der Vergangenheit liegen `exp` claim must not be in the past | exp, nbf exp, nbf
Scopes / Rollen Scopes / roles | Erforderliche Berechtigungen im `scp` oder `roles`-Claim prüfen Check required permissions in `scp` or `roles` claim | scp, roles scp, roles

## Microsoft Identity Endpoints Microsoft identity endpoints

Microsoft Entra ID stellt mehrere Endpoints für verschiedene Protokolle bereit. Die wichtigsten Basis-URLs sind die `v2.0`-Endpoints (empfohlen) und der `v1.0`-Endpoint (Legacy). Microsoft Entra ID provides several endpoints for different protocols. The main base URLs are the `v2.0` endpoints (recommended) and the `v1.0` endpoint (legacy).

Endpunkt Endpoint | URL URL | Verwendung Usage
--- | --- | ---
Autorisierung Authorization | https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize | OAuth 2.0, OIDC OAuth 2.0, OIDC
Token Token | https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token | OAuth 2.0, OIDC OAuth 2.0, OIDC
OpenID Configuration OpenID Configuration | https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration | OIDC Discovery OIDC Discovery
JWKS JWKS | https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys | Signaturschlüssel Signing keys
SAML Sign-In SAML Sign-In | https://login.microsoftonline.com/{tenant}/saml2 https://login.microsoftonline.com/{tenant}/saml2 | SAML 2.0 SAML 2.0
SAML Sign-Out SAML Sign-Out | https://login.microsoftonline.com/{tenant}/saml2 https://login.microsoftonline.com/{tenant}/saml2 | SAML SLO SAML SLO
WS-Federation WS-Federation | https://login.microsoftonline.com/{tenant}/wsfed https://login.microsoftonline.com/{tenant}/wsfed | WS-Fed WS-Fed
UserInfo UserInfo | https://graph.microsoft.com/oidc/userinfo https://graph.microsoft.com/oidc/userinfo | OIDC UserInfo OIDC UserInfo

## Zertifikate und Schlüssel Certificates and keys

Microsoft Entra ID verwendet RSA-Schlüssel zum Signieren von Tokens. Die öffentlichen Schlüssel werden über den JWKS-Endpunkt bereitgestellt und regelmäßig rotiert. Anwendungen sollten Schlüssel dynamisch abrufen und cachen. Microsoft Entra ID uses RSA keys to sign tokens. The public keys are provided via the JWKS endpoint and regularly rotated. Applications should dynamically retrieve and cache keys.

Aspekt Aspect | Detail Detail
--- | ---
Algorithmus Algorithm | RS256 (RSA + SHA-256)RS256 (RSA + SHA-256)
Schlüssellänge Key size | 2048 Bit 2048 Bit
Rotation Rotation | Alle 6 Wochen (automatisch); Notfall-Rotation möglich Every 6 weeks (automatic); emergency rotation possible
JWKS-Caching JWKS caching | 24 Stunden empfohlen; bei 401-Fehler sofort neu laden 24 hours recommended; reload immediately on 401 error
SAML-Zertifikat SAML certificate | 3 Jahre Standard; verlängerbar per Portal oder PowerShell 3 years default; renewable via portal or PowerShell

⚠️ SAML-Zertifikats-Ablauf⚠️ SAML certificate expiry

Ein abgelaufenes SAML-Signaturzertifikat führt zu sofortigem SSO-Ausfall. Richten Sie Alerting für Zertifikatsabläufe über Entra-Empfehlungen oder Monitoring-Scripts ein. An expired SAML signing certificate causes immediate SSO failure. Set up alerting for certificate expiry via Entra recommendations or monitoring scripts.

## Verwandte Seiten Related pages

- App-Registrierungen App Registrations
- Conditional Access Conditional Access
- MFA MFA
- Graph API Graph API
- External ID External ID