Übersicht über Token und Ansprüche

  • Artikel

Ein zentraler Identitätsanbieter ist besonders nützlich für Apps mit weltweit verteilten Benutzer*innen, die sich nicht immer über das Netzwerk des Unternehmens anmelden. Microsoft Identity Platform authentifiziert Benutzer und stellt Sicherheitstoken bereit, wie z. B. Zugriffstoken, Aktualisierungstoken und ID-Token. Mit Sicherheitstoken kann eine Clientanwendung auf geschützte Ressourcen auf einem Ressourcenserver zugreifen.

  • Zugriffstoken: Ein Zugriffstoken ist ein Sicherheits-Token, der von einem Autorisierungsserver als Teil eines OAuth 2. 0-Flows ausgegeben wird. Es enthält Informationen zum Benutzer und zu der Ressource, für die das Token vorgesehen ist. Die Informationen können für den Zugriff auf Web-APIs und andere geschützte Ressourcen verwendet werden. Ressourcen validieren Zugriffstoken, um den Zugriff auf eine Client-Anwendung zu gewähren. Weitere Informationen finden Sie unter Zugriffstoken in der Microsoft Identitätsplattform.
  • Aktualisierungstoken: Da Zugriffstoken nur für einen kurzen Zeitraum gültig sind, stellen Autorisierungsserver manchmal gleichzeitig mit dem Zugriffstoken ein Aktualisierungstoken aus. Die Clientanwendung kann dann dieses Aktualisierungstoken bei Bedarf gegen ein neues Zugriffstoken austauschen. Weitere Informationen finden Sie unter Aktualisierungstoken in der Microsoft Identitätsplattform.
  • ID-Token: ID-Token werden als Teil eines OpenID Connect-Flows an die Clientanwendung gesendet. Sie können zusammen mit einem Zugriffstoken oder anstelle dessen gesendet werden. Mithilfe des ID-Tokens authentifiziert der Client den Benutzer. Weitere Informationen darüber, wie die Microsoft-Identitätsplattform ID-Token ausstellt, finden Sie unter ID-Token in der Microsoft-Identitätsplattform.

Viele Unternehmensanwendungen verwenden SAML zum Authentifizieren von Benutzern. Informationen zu SAML-Assertions finden Sie in der SAML-Tokenreferenz.

Überprüfen von Token

Die Anwendung, für die das Token generiert wurde, die Webanwendung, die den Benutzer anmeldet, oder die aufgerufene Web-API müssen das Token validieren. Der Autorisierungsserver signiert das Token mit einem privaten Schlüssel. Der Autorisierungsserver veröffentlicht den entsprechenden öffentlichen Schlüssel. Zur Überprüfung eines Tokens verifiziert die App die Signatur, indem mit dem öffentlichen Schlüssel vom Autorisierungsserver überprüft wird, ob die Signatur mit dem privaten Schlüssel erstellt wurde. Für weitere Informationen lesen Sie den Artikel Sichern von Anwendungen und APIs durch Überprüfen von Ansprüchen.

Es wird empfohlen, die unterstützten Microsoft-Authentifizierungsbibliotheken (MSAL) nach Möglichkeit zu verwenden. Dadurch wird der Erwerb, die Aktualisierung und die Validierung von Token für Sie implementiert. Es implementiert außerdem die standardkonforme Ermittlung von Mandanteneinstellungen und Schlüsseln mithilfe des openID-Ermittlungsdokuments des Mandanten. MSAL unterstützt verschiedene Anwendungsarchitekturen und -plattformen einschließlich .NET, JavaScript, Java, Python, Android und iOS.

Token sind nur für eine begrenzte Zeit gültig, daher stellt der Autorisierungsserver häufig ein Token-Paar zur Verfügung. Es wird ein Zugriffstoken bereitgestellt, das auf die Anwendung oder die geschützte Ressource zugreift. Ein Aktualisierungstoken wird bereitgestellt, mit dem das Zugriffstoken aktualisiert werden kann, wenn das Zugriffstoken bald abläuft.

Zugriffstoken werden als Bearertoken im Authorization-Header an eine Web-API übergeben. Eine App kann ein Aktualisierungstoken an den Autorisierungsserver übergeben. Wenn dem Benutzer der Zugriff auf die App nicht entzogen wurde, erhält er ein neues Zugriffstoken und ein neues Aktualisierungstoken. Wenn der Autorisierungsserver das Aktualisierungstoken erhält, stellt er nur dann ein weiteres Zugriffstoken aus, falls der Benutzer noch berechtigt ist.

JSON Web Token und Ansprüche

Microsoft Identity Platform implementiert Sicherheitstoken als JSON Web Token (JWTs), die Ansprüche enthalten. Da JWT-Token als Sicherheitstoken verwendet werden, wird diese Art der Authentifizierung manchmal auch als JWT-Authentifizierung bezeichnet.

Ein Anspruch stellt Assertionen zu einer Entität (z. B. Clientanwendung oder Ressourcenbesitzer) für eine andere Entität (z. B. Ressourcenserver) bereit. Ein Anspruch kann auch als JWT-Anspruch bzw. JSON Web Token-Anspruch bezeichnet werden.

Ansprüche sind Name-Wert-Paare zur Weitergabe von Informationen zum Tokenantragsteller. Eine Anfrage kann zum Beispiel Fakten über den Sicherheitsprinzipal enthalten, den der Autorisierungsserver authentifiziert hat. Welche Ansprüche in einem Token enthalten sind, hängt von verschiedenen Dingen ab. Hierzu zählen unter anderem die Art des Tokens, die Art der Anmeldeinformationen für die Authentifizierung des Antragstellers und die Anwendungskonfiguration.

Anwendungen können Anfragen für die folgenden verschiedenen Aufgaben verwenden:

  • Überprüfen des Tokens
  • Identifizierung des Mandanten des Tokenantragstellers
  • Anzeigen der Benutzerinformationen
  • Bestimmen der Autorisierung des Antragstellers

Eine Anfrage besteht aus Schlüsselwertpaaren mit den folgenden Informationsarten:

  • Sicherheitstoken-Server, der den Token erzeugt hat
  • Datum, an dem das Token generiert wurde
  • Antragsteller (wie der Benutzer, aber keine Daemons)
  • Zielgruppe, d. h. App, für die das Token generiert wurde
  • App (der Client), die das Token angefordert hat

Tokenendpunkte und Aussteller

Die Microsoft Entra-ID unterstützt zwei Mandantenkonfigurationen: eine Personalkonfiguration, die für die interne Verwendung vorgesehen ist und Mitarbeiter und Unternehmensgäste verwaltet, sowie eine Kundenkonfiguration, die für die Isolierung von Verbrauchern und Partnern in einem eingeschränkten externen Verzeichnis optimiert ist. Während der zugrunde liegende Identitätsdienst für beide Mandantenkonfigurationen identisch ist, unterscheiden sich die Anmeldedomänen und die tokenausstellende Autorität für externe Mandanten. Auf diese Weise können Anwendungen Mitarbeiter- und externe ID-Workflows bei Bedarf getrennt halten.

Microsoft Entra-Mitarbeitermandanten authentifizieren sich bei login.microsoftonline.com mit Token, die von sts.windows.net ausgestellt wurden. Mandantentoken für Mitarbeiter sind in der Regel über Mandanten und Mandantenanwendungen hinweg austauschbar, solange zugrunde liegende Vertrauensbeziehungen diese Interoperabilität zulassen. Externe Microsoft Entra-Mandanten verwenden mandantenfähige Endpunkte des Formulars {tenantname}.ciamlogin.com. Anwendungen, die für externe Mandanten registriert sind, müssen diese Trennung kennen, um Token ordnungsgemäß zu empfangen und zu validieren.

Jeder Microsoft Entra-Mandant veröffentlicht eine standardkonforme bekannte Metadaten. Dieses Dokument enthält Informationen über den Ausstellernamen, die Authentifizierungs- und Autorisierungsendpunkte, unterstützte Bereiche und Ansprüche. Für externe Mandanten ist das Dokument öffentlich verfügbar unter: https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. Dieser Endpunkt gibt einen Ausstellerwert https://{tenantid}.ciamlogin.com/{tenantid}/v2.0zurück.

Autorisierungs-Flows und Authentifizierungscodes

Je nachdem, wie Ihr Client aufgebaut ist, kann er einen oder mehrere der von der Microsoft-Identitätsplattform unterstützten Authentifizierungsabläufe verwenden. Die unterstützten Flows können verschiedene Token-Typen und Autorisierungscodes erzeugen und erfordern unterschiedliche Token, damit sie funktionieren. Die folgende Tabelle bietet eine Übersicht.

Flow Erforderlich ID-Token Zugriffstoken Aktualisierungstoken Authorization code (Autorisierungscode)
Autorisierungscodeflow x x x x
Impliziter Flow x x
Hybrid-OIDC-Ablauf x x
Einlösung des Aktualisierungstokens Aktualisierungstoken x x x
„Im Auftrag von“-Ablauf Zugriffstoken x x x
Clientanmeldeinformationen x (nur App)

Token, die über den impliziten Flow ausgegeben werden, sind in ihrer Länge begrenzt, da sie über die URL an den Browser zurückgegeben werden, wobei response_mode , query oder fragment ist. Bei einigen Browsern gilt eine Größenbeschränkung für die URL, die in die Browserleiste eingefügt werden kann. Es tritt ein Fehler auf, wenn die URL zu lang ist. Daher verfügen diese Token nicht über die Ansprüche groups oder wids.

Siehe auch

Nächste Schritte