Freigeben über


AD FS OpenID Connect/OAuth-Konzepte

Gilt für Active Directory-Verbunddienste (AD FS) 2016 und höher

Moderne Authentifizierungsakteure

Actor (Schauspieler) BESCHREIBUNG
Endbenutzer Der Sicherheitsprinzipal (Benutzende, Anwendungen, Dienste und Gruppen), der auf die Ressource zugreifen muss.
Kunde Ihre Webanwendung, die durch ihre Client-ID identifiziert wird. Der Client ist in der Regel die Partei, mit der der Endbenutzer interagiert, und der Client fordert Token vom Autorisierungsserver an.
Autorisierungsserver/Identitätsanbieter (IdP) Ihr AD FS-Server. Sie ist für die Überprüfung der Identität von Sicherheitsprinzipalen verantwortlich, die im Verzeichnis einer Organisation vorhanden sind. Es gibt Sicherheitstoken (Bearerzugriffstoken, ID-Token und Aktualisierungstoken) bei erfolgreicher Authentifizierung dieser Sicherheitsprinzipale aus.
Ressourcenserver/Ressourcenanbieter/Vertrauende Seite Wo sich die Ressource oder die Daten befinden. Er vertraut dem Autorisierungsserver, um den Client sicher zu authentifizieren und zu autorisieren, und verwendet Bearer-Zugriffstoken, um sicherzustellen, dass der Zugriff auf eine Ressource gewährt werden kann.

Das folgende Diagramm stellt die grundlegendste Beziehung zwischen den Akteuren bereit:

Diagramm der modernen Authentifizierungsakteure.

Anwendungstypen

Anwendungstyp BESCHREIBUNG Rolle
Native Anwendung Manchmal auch als öffentlicher Client bezeichnet. Es ist eine Client-App, die auf einem Pc oder Gerät ausgeführt wird und mit der der Benutzer interagiert. Fordert Token vom Autorisierungsserver (AD FS) für den Benutzerzugriff auf Ressourcen an. Sendet HTTP-Anforderungen an geschützte Ressourcen, indem die Token als HTTP-Header verwendet werden.
Serveranwendung (Web-App) Eine Webanwendung, die auf einem Server ausgeführt wird und über einen Browser für Benutzer zugänglich ist. Da es in der Lage ist, seinen eigenen geheimen Clientschlüssel oder Anmeldeinformationen zu verwalten, wird er manchmal als vertraulicher Client bezeichnet. Fordert Token vom Autorisierungsserver (AD FS) für den Benutzerzugriff auf Ressourcen an. Bevor ein Token anfordert, muss der Client (Web-App) sich mithilfe seines geheimen Schlüssels authentifizieren.
Web-API Die Endquelle, auf die der Benutzer zugreift. Stellen Sie sich das als die neue Vertretung der vertrauenden Parteien vor. Nutzt Bearerzugriffstoken, die von den Clients abgerufen wurden.

Anwendungsgruppe

Sie müssen jeder nativen OAuth-Client- oder Web-API-Ressource, die mit AD FS konfiguriert ist, eine Anwendungsgruppe zuordnen. Konfigurieren Sie die Clients in einer Anwendungsgruppe, um auf die Ressourcen in derselben Gruppe zuzugreifen. Eine Anwendungsgruppe kann über mehrere Clients und Ressourcen verfügen.

Sicherheitstoken

Die moderne Authentifizierung verwendet die folgenden Tokentypen:

  • id_token: Ein JWT-Token, das vom Autorisierungsserver (AD FS) ausgestellt und vom Client genutzt wird. Ansprüche im ID-Token enthalten Informationen über die benutzendePerson, sodass der Client diese verwenden kann.
  • access_token: Ein JWT-Token, das vom Autorisierungsserver (AD FS) ausgestellt wurde und von der Ressource verwendet werden soll. Der „aud“- oder „audience“-Anspruch dieses Tokens muss mit dem Bezeichner der Ressource oder Web-API übereinstimmen.
  • refresh_token: Ausgestellt von AD FS, damit der Client die id_tokens und access_tokens aktualisieren kann, wenn dies erforderlich ist. Das Token ist für den Client nicht transparent und wird nur von AD FS genutzt.

Lebensdauern von Aktualisierungstoken

  • Einfache Anmeldung, kein KMSI, Gerät nicht registriert: AD FS wendet SsoLifetime und DeviceUsageWindowInDays an. Das erste Refreshtoken ist entweder lifetime=DeviceUsageWindowInDays oder SsoLifetime, je nachdem, welches Feld niedriger ist, aber keine weiteren Refreshtokens werden ausgegeben.
  • KMSI-Anmeldung, EnableKmsi=true in AD FS-Konfiguration und kmsi=true als Parameter übergeben: AD FS wendet KmsiLifetimeMins mit DeviceUsageWindowInDays an. Das erste Aktualisierungstoken hat lifetime=DeviceUsageWindowInDays und jede nachfolgende grant_type=refresh_token Anforderung erhält ein neues Aktualisierungstoken. Dieser Vorgang erfolgt nur bei nativen Clients oder vertraulichen Clients, plus Geräteauthentifizierung.
  • Registrierte Geräte, Geräteauthentifizierung: AD FS verwendet PersistentSsoLifetimeMins und DeviceUsageWindowInDays, die ähnlich wie KMSI funktionieren. Sowohl native als auch vertrauliche Clients sollten neue Aktualisierungstoken basierend auf der Geräteauthentifizierung erhalten.

Weitere Informationen finden Sie in der Dokumentation zum einmaligen Anmelden von AD FS.

Geltungsbereiche

Wenn Sie eine Ressource in AD FS registrieren, können Sie Bereiche konfigurieren, damit AD FS bestimmte Aktionen ausführen kann. Zusätzlich zum Konfigurieren des Bereichs müssen Sie den Bereichswert in der Anforderung senden, damit AD FS die Aktion ausführen kann. Beispielsweise konfiguriert ein Administrator den Bereich als openid während der Ressourcenregistrierung, und die Anwendung (Client) muss den scope = openid in der Authentifizierungsanfrage senden, damit AD FS das ID-Token ausstellt. Im Folgenden finden Sie Details zu den verfügbaren Bereichen in AD FS:

  • aza - Wenn Sie OAuth 2.0-Protokollerweiterungen für Brokerclients verwenden und wenn der Bereichsparameter den Bereich azaenthält, gibt der Server ein neues primäres Aktualisierungstoken aus. Es legt das Token im refresh_token Feld der Antwort fest und legt die refresh_token_expires_in field Lebensdauer des neuen primären Aktualisierungstokens fest, wenn eine erzwungen wird.
  • openid – Ermöglicht der Anwendungsanforderung die Verwendung des openid Verbindungsauthentifizierungsprotokolls.
  • logon_cert – Ermöglicht es einer Anwendung, Anmeldezertifikate anzufordern, mit denen Sie sich interaktiv bei authentifizierten Benutzern anmelden können. Der AD FS-Server lässt den access_token Parameter aus der Antwort aus und stellt stattdessen eine base64-codierte CMS-Zertifikatkette oder eine CMC-vollständige PKI-Antwort bereit. Weitere Informationen finden Sie unter MS-OAPX: OAuth 2.0-Protokollerweiterungen.
  • user_impersonation: Fordert ein On-Behalf-Of-Zugriffstoken von AD FS an. Ausführliche Informationen zur Verwendung dieses Bereichs finden Sie unter Erstellen einer mehrstufigen Anwendung mit On-Behalf-Of (OBO) mit OAuth mit AD FS 2016.
  • allatclaims – Ermöglicht der Anwendung, die Ansprüche im Zugriffstoken anzufordern, um sie dem ID-Token hinzuzufügen.
  • vpn_cert – Ermöglicht es einer Anwendung, VPN-Zertifikate anzufordern, die VPN-Verbindungen mithilfe EAP-TLS Authentifizierung herstellen. Dieses Feature wird nicht mehr unterstützt.
  • email – Ermöglicht der Anwendung, einen E-Mail-Anspruch für den angemeldeten Benutzer anzufordern.
  • profile – Ermöglicht es der Anwendung, profilbezogene Ansprüche für den angemeldeten Benutzer anzufordern.

Ansprüche

Sicherheitstoken (Zugriffs- und ID-Token), die von AD FS ausgestellt werden, enthalten Berechtigungsnachweise oder Behauptungen von Informationen über das Subjekt, das authentifiziert wurde. Anwendungen können Ansprüche für verschiedene Aufgaben verwenden, einschließlich:

  • Überprüfen des Tokens
  • Identifizieren Sie den Verzeichnismandanten des Subjekts
  • Anzeigen von Benutzerinformationen
  • Die Berechtigung des Subjekts bestimmen

Die Ansprüche, die in einem bestimmten Sicherheitstoken vorhanden sind, sind vom Tokentyp, dem Typ der Anmeldeinformationen, die zum Authentifizieren des Benutzers und zur Anwendungskonfiguration verwendet werden, abhängig.

Ad FS-Authentifizierungsfluss auf hoher Ebene

Hier sehen Sie eine Abbildung des allgemeinen Ablaufs:

Diagramm des AD FS-Authentifizierungsflusses.

  1. AD FS empfängt eine Authentifizierungsanforderung vom Client.

  2. AD FS überprüft die Client-ID in der Authentifizierungsanforderung mit der Client-ID, die während der Client- und Ressourcenregistrierung in AD FS abgerufen wurde. Bei Verwendung eines vertraulichen Clients überprüft AD FS auch den in der Authentifizierungsanforderung bereitgestellten geheimen Clientschlüssel. AD FS überprüft auch den Umleitungs-URI des Clients.

  3. AD FS identifiziert die Ressource, auf die der Client über den Ressourcenparameter zugreifen möchte, der in der Authentifizierungsanforderung übergeben wird. Wenn Sie die MSAL-Clientbibliothek verwenden, wird der Ressourcenparameter nicht gesendet. Stattdessen wird die Ressourcen-URL als Teil des Bereichsparameters gesendet: scope = [resource url]/[scope values, for example, openid].

    Wenn die Ressource nicht mithilfe der Ressourcen- oder Bereichsparameter übergeben wird, verwendet AD FS eine Standardressource urn:microsoft:userinfo , deren Richtlinien, z. B. MFA, Ausstellungs- oder Autorisierungsrichtlinie, nicht konfiguriert werden können.

  4. Als Nächstes überprüft AD FS, ob der Client über Berechtigungen für den Zugriff auf die Ressource verfügt. AD FS überprüft außerdem, ob die in der Authentifizierungsanforderung übergebenen Bereiche mit den bei der Registrierung der Ressource konfigurierten Bereichen übereinstimmen. Wenn der Client nicht über die Berechtigungen verfügt oder die richtigen Bereiche nicht in der Authentifizierungsanforderung gesendet werden, wird der Authentifizierungsfluss beendet.

  5. Sobald Berechtigungen und Bereiche überprüft wurden, authentifiziert AD FS den Benutzer mithilfe der konfigurierten Authentifizierungsmethode.

  6. Wenn eine andere Authentifizierungsmethode gemäß der Ressourcenrichtlinie oder der globalen Authentifizierungsrichtlinie erforderlich ist, löst AD FS die zusätzliche Authentifizierung aus.

  7. AD FS verwendet die mehrstufige Microsoft Entra-Authentifizierung oder die mehrstufige Authentifizierung von Drittanbietern , um die Authentifizierung durchzuführen.

  8. Sobald der Benutzer authentifiziert wurde, wendet AD FS die Anspruchsregeln an. Anspruchsregeln bestimmen die Ansprüche, die als Teil der Sicherheitstoken an die Ressource gesendet werden. AD FS wendet auch die Zugriffssteuerungsrichtlinien an, die bestätigen, dass der Benutzer die erforderlichen Bedingungen für den Zugriff auf die Ressource erfüllt.

  9. Als Nächstes generiert AD FS den Zugriff und aktualisiert die Token. AD FS generiert auch das ID-Token.

  10. AD FS empfängt die Authentifizierungsanforderung.

  11. Wenn Sie das scope = allatclaims in der Authentifizierungsanforderung einschließen, wird das ID-Token angepasst, sodass Ansprüche basierend auf den definierten Anspruchsregeln im Zugriffstoken enthalten sind.

  12. Sobald die erforderlichen Token generiert und angepasst wurden, antwortet AD FS dem Client und nimmt die Token auf. Die ID-Tokenantwort ist nur in der Antwort enthalten, wenn die Authentifizierungsanforderung enthalten ist scope = openid. Der Client kann das ID-Token nach der Authentifizierung immer mithilfe des Tokenendpunkts abrufen.

Arten von Bibliotheken

Verwenden Sie zwei Arten von Bibliotheken mit AD FS:

  • Clientbibliotheken: Native Clients und Server-Apps verwenden Clientbibliotheken, um Zugriffstoken zum Aufrufen einer Ressource wie einer Web-API abzurufen. Microsoft Authentication Library (MSAL) ist die neueste und empfohlene Clientbibliothek, wenn Sie AD FS 2019 verwenden.

  • Server-Middlewarebibliotheken: Web-Apps verwenden Server-Middlewarebibliotheken für die Benutzeranmeldung. Web-APIs verwenden Server-Middlewarebibliotheken, um Token zu überprüfen, die von systemeigenen Clients oder von anderen Servern gesendet werden. Open Web Interface for .NET (OWIN) ist die empfohlene Middleware-Bibliothek.

Anpassen des ID-Tokens (zusätzliche Ansprüche im ID-Token)

In bestimmten Szenarien ist es möglich, dass der Web-App-Client zusätzliche Ansprüche in einem ID-Token benötigt, um die Funktionalität zu unterstützen. Richten Sie zusätzliche Ansprüche in einem ID-Token mithilfe einer der folgenden Optionen ein:

Option 1: Verwenden Sie diese Option, wenn Sie über einen öffentlichen Client verfügen und die Web-App nicht über eine Ressource verfügt, auf die sie zugreifen möchte. Diese Option erfordert:

  • response_mode ist festgelegt als form_post
  • Der Bezeichner der vertrauenden Seite (Web-API-ID) entspricht dem Clientbezeichner.

Diagramm der AD FS-Anpassungstokenoption 1.

Option 2: Verwenden Sie diese Option, wenn die Web-App über eine Ressource verfügt, auf die sie zugreifen möchte und zusätzliche Ansprüche über das ID-Token übergeben muss. Sie können öffentliche und vertrauliche Clients verwenden. Diese Option erfordert:

  • response_mode ist festgelegt als form_post

  • KB4019472 auf Ihren AD FS-Servern installiert ist

  • Der Bereich allatclaims ist dem Client-RP-Paar zugewiesen. Sie können den Bereich mithilfe von Grant-ADFSApplicationPermission zuweisen. Verwenden Sie Set-AdfsApplicationPermission, wenn es bereits einmal gewährt wurde. Das PowerShell-Cmdlet wird im folgenden Beispiel angegeben:

    Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
    

Diagramm der AD FS-Anpassungstokenoption 2.

Informationen zum Konfigurieren einer Web-App in AD FS zum Abrufen eines angepassten ID-Tokens finden Sie unter "Benutzerdefinierte ID-Token" in AD FS 2016 oder höher.

Einmaliges Abmelden

Durch einmaliges Abmelden werden alle Clientsitzungen beendet, die die Sitzungs-ID verwenden. AD FS 2016 und höher unterstützt einmaliges Abmelden für OpenID Connect/OAuth. Weitere Informationen finden Sie unter Einmaliges Abmelden für OpenID Connect mit AD FS.

AD FS-Endpunkte

AD FS-Endpunkt BESCHREIBUNG
/autorisieren AD FS gibt einen Autorisierungscode zurück, den Sie zum Abrufen des Zugriffstokens verwenden können.
/Zeichen AD FS gibt ein Zugriffstoken zurück, mit dem Sie wie in der Web-API auf die Ressource zugreifen können.
/Benutzerinfo AD FS gibt den Antragstelleranspruch zurück.
/devicecode AD FS gibt den Gerätecode und den Benutzercode zurück.
/Abmeldung AD FS meldet den Benutzer ab.
/Tasten Öffentliche AD FS-Schlüssel, die zum Signieren von Antworten verwendet werden
/.well-known/openid-konfiguration AD FS gibt OAuth/OpenID Connect-Metadaten zurück.