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.

ÜberblickOverview

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.

OAuth 2.0 – GrundprinzipOAuth 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.

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

Authorization Code Flow mit PKCE – SchrittübersichtAuthorization 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).

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

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.

Standard-Scopes (OIDC)Standard scopes (OIDC)

Token-TypenToken types

Wichtige Claims im Access TokenKey claims in access token

SAML 2.0SAML 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.

SAML Assertion-Strukturassertion structure

<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>

WS-FederationWS-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.

Legacy-AuthentifizierungLegacy 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).

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-TransformationenClaims 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.

{
  "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.

Token-Lifetime-KonfigurationToken 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.

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-DebuggingSAML 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.

Workload-Identitäten und ProtokolleWorkload 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.

Token-ValidierungToken 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.

Microsoft Identity EndpointsMicrosoft 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).

Zertifikate und SchlüsselCertificates 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.

Verwandte SeitenRelated pages

• App-RegistrierungenApp Registrations
• Conditional AccessConditional Access
• MFAMFA
• Graph APIGraph API
• External IDExternal ID