Microsoft Identity Platform – ID-Token

  • Artikel

Der Autorisierungsserver stellt ID-Token aus, die Ansprüche mit den Informationen über den Benutzer enthalten. Sie können zusammen mit einem Zugriffstoken oder anstelle dessen gesendet werden. Die Informationen in den ID-Tokens ermöglichen es dem Client zu überprüfen, ob ein Benutzer derjenige ist, der er vorgibt zu sein.

Anwendungen von Drittanbietern sollen ID-Token verstehen. Die ID-Token sollten nicht zu Autorisierungszwecken verwendet werden. Die Zugriffstoken werden für die Autorisierung verwendet. Die von den ID-Token bereitgestellten Ansprüche können für die Benutzeroberfläche in Ihrer Anwendung, als Schlüssel in einer Datenbank, verwendet werden. Sie können außerdem den Zugriff auf die Clientanwendung bereitstellen. Weitere Informationen zu den in einem ID-Token verwendeten Ansprüchen finden Sie in der Referenz der ID-Tokenansprüche. Weitere Informationen zur anspruchsbasierten Autorisierung finden Sie unter Sichern von Anwendungen und APIs durch Überprüfen von Ansprüchen.

Tokenformate

Es gibt zwei Versionen von ID-Token, die in Microsoft Identity Platform verfügbar sind: v1.0 und v2.0. Diese Versionen bestimmen die im Token vorhandenen Ansprüche. Die ID-Token v1.0 und v2.0 tragen unterschiedliche Informationen. Die Version basiert auf dem Endpunkt, von dem aus die Anforderung erfolgt ist. Neue Anwendungen sollten v2.0 verwenden.

  • v1.0: https://login.microsoftonline.com/common/oauth2/authorize
  • v2.0: https://login.microsoftonline.com/common/oauth2/v2.0/authorize

Beispiel: Ein v1.0 ID-Token

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjdfWnVmMXR2a3dMeFlhSFMzcTZsVWpVWUlHdyIsImtpZCI6IjdfWnVmMXR2a3dMeFlhSFMzcTZsVWpVWUlHdyJ9.eyJhdWQiOiJiMTRhNzUwNS05NmU5LTQ5MjctOTFlOC0wNjAxZDBmYzljYWEiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkvIiwiaWF0IjoxNTM2Mjc1MTI0LCJuYmYiOjE1MzYyNzUxMjQsImV4cCI6MTUzNjI3OTAyNCwiYWlvIjoiQVhRQWkvOElBQUFBcXhzdUIrUjREMnJGUXFPRVRPNFlkWGJMRDlrWjh4ZlhhZGVBTTBRMk5rTlQ1aXpmZzN1d2JXU1hodVNTajZVVDVoeTJENldxQXBCNWpLQTZaZ1o5ay9TVTI3dVY5Y2V0WGZMT3RwTnR0Z2s1RGNCdGsrTExzdHovSmcrZ1lSbXY5YlVVNFhscGhUYzZDODZKbWoxRkN3PT0iLCJhbXIiOlsicnNhIl0sImVtYWlsIjoiYWJlbGlAbWljcm9zb2Z0LmNvbSIsImZhbWlseV9uYW1lIjoiTGluY29sbiIsImdpdmVuX25hbWUiOiJBYmUiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMWRiNDcvIiwiaXBhZGRyIjoiMTMxLjEwNy4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJub25jZSI6IjEyMzUyMyIsIm9pZCI6IjA1ODMzYjZiLWFhMWQtNDJkNC05ZWMwLTFiMmJiOTE5NDQzOCIsInJoIjoiSSIsInN1YiI6IjVfSjlyU3NzOC1qdnRfSWN1NnVlUk5MOHhYYjhMRjRGc2dfS29vQzJSSlEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6IkFiZUxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJMeGVfNDZHcVRrT3BHU2ZUbG40RUFBIiwidmVyIjoiMS4wIn0=.UJQrCA6qn2bXq57qzGX_-D3HcPHqBMOKDPx4su1yKRLNErVD8xkxJLNLVRdASHqEcpyDctbdHccu6DPpkq5f0ibcaQFhejQNcABidJCTz0Bb2AbdUCTqAzdt9pdgQvMBnVH1xk3SCM6d4BbT4BkLLj10ZLasX7vRknaSjE_C5DI7Fg4WrZPwOhII1dB0HEZ_qpNaYXEiy-o94UJ94zCr07GgrqMsfYQqFR7kn-mn68AjvLcgwSfZvyR_yIK75S_K37vC3QryQ7cNoafDe9upql_6pB2ybMVlgWPs_DmbJ8g0om-sPlwyn74Cc1tW3ze-Xptw_2uVdPgWyqfuWAfq6Q

Zeigen Sie dieses v1. 0-Beispieltoken in jwt.ms an.

Beispiel: Ein v2.0 ID-Token

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjFMVE16YWtpaGlSbGFfOHoyQkVKVlhlV01xbyJ9.eyJ2ZXIiOiIyLjAiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vOTEyMjA0MGQtNmM2Ny00YzViLWIxMTItMzZhMzA0YjY2ZGFkL3YyLjAiLCJzdWIiOiJBQUFBQUFBQUFBQUFBQUFBQUFBQUFJa3pxRlZyU2FTYUZIeTc4MmJidGFRIiwiYXVkIjoiNmNiMDQwMTgtYTNmNS00NmE3LWI5OTUtOTQwYzc4ZjVhZWYzIiwiZXhwIjoxNTM2MzYxNDExLCJpYXQiOjE1MzYyNzQ3MTEsIm5iZiI6MTUzNjI3NDcxMSwibmFtZSI6IkFiZSBMaW5jb2xuIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiQWJlTGlAbWljcm9zb2Z0LmNvbSIsIm9pZCI6IjAwMDAwMDAwLTAwMDAtMDAwMC02NmYzLTMzMzJlY2E3ZWE4MSIsInRpZCI6IjkxMjIwNDBkLTZjNjctNGM1Yi1iMTEyLTM2YTMwNGI2NmRhZCIsIm5vbmNlIjoiMTIzNTIzIiwiYWlvIjoiRGYyVVZYTDFpeCFsTUNXTVNPSkJjRmF0emNHZnZGR2hqS3Y4cTVnMHg3MzJkUjVNQjVCaXN2R1FPN1lXQnlqZDhpUURMcSFlR2JJRGFreXA1bW5PcmNkcUhlWVNubHRlcFFtUnA2QUlaOGpZIn0.1AFWW-Ck5nROwSlltm7GzZvDwUkqvhSQpm55TQsmVo9Y59cLhRXpvB8n-55HCr9Z6G_31_UbeUkoz612I2j_Sm9FFShSDDjoaLQr54CreGIJvjtmS3EkK9a7SJBbcpL1MpUtlfygow39tFjY7EVNW9plWUvRrTgVk7lYLprvfzw-CIqw3gHC-T7IK_m_xkr08INERBtaecwhTeN4chPC4W3jdmw_lIxzC48YoQ0dB1L9-ImX98Egypfrlbm0IBL5spFzL6JDZIRRJOu8vecJvj1mq-IUhGt0MacxX8jdxYLP-KUu2d9MbNKpCKJuZ7p8gwTL5B7NlUdh_dmSviPWrw

Zeigen Sie dieses v2. 0-Beispieltoken in jwt.ms an.

Lebensdauer von Token

Standardmäßig ist ein ID-Token eine Stunde lang gültig. Nach einer Stunde muss der Client ein neues ID-Token beziehen.

Sie können die Gültigkeitsdauer eines ID-Tokens anpassen, um zu steuern, wie oft die Clientanwendung den Ablauf der Anwendungssitzung veranlasst und wie oft eine erneute Authentifizierung des Benutzers erforderlich ist (entweder im Hintergrund oder interaktiv). Weitere Informationen hierzu finden Sie unter Konfigurierbare Tokengültigkeitsdauer.

Überprüfen von Token

Um das ID-Token zu überprüfen, kann Ihr Client prüfen, ob das Token manipuliert wurde. Außerdem kann der Aussteller überprüft werden, um sicherzustellen, dass der richtige Aussteller das Token zurückgesendet hat. Da die ID-Token immer JWT-Token sind, sind zahlreiche Bibliotheken zum Überprüfen dieser Token verfügbar. Sie sollten eine dieser Bibliotheken verwenden, anstatt den Vorgang selbst auszuführen. Nur vertrauliche Clients sollten ID-Token überprüfen. Weitere Informationen finden Sie unter Sichern von Anwendungen und APIs durch Überprüfen von Ansprüchen.

Öffentliche Anwendungen (ein Code, der vollständig auf einem Gerät oder in einem Netzwerk ausgeführt wird, das Sie nicht steuern können, z. B. den Browser eines Benutzers oder dessen Heimnetzwerk) profitieren nicht von der Überprüfung des ID-Tokens. In diesem Fall kann ein böswilliger Benutzer die Schlüssel abfangen und bearbeiten, die für die Überprüfung des Tokens verwendet werden.

Die folgenden JWT-Ansprüche sollten im ID-Token überprüft werden, nachdem die Signatur für das Token überprüft wurde. Ihre Tokenüberprüfungsbibliothek überprüft möglicherweise auch die folgenden Ansprüche:

  • Zeitstempel: Die Zeitstempel iat, nbf und exp sollten alle vor oder nach der aktuellen Zeit liegen (je nach Bedarf).
  • Zielgruppe: Der aud-Anspruch sollte mit der App-ID Ihrer Anwendung übereinstimmen.
  • Nonce: Der nonce-Anspruch in der Nutzlast muss mit dem nonce-Parameter übereinstimmen, der während der ersten Anforderung an den /authorize-Endpunkt übergeben wurde.

Siehe auch

Nächste Schritte

  • Schauen Sie sich den OpenID Connect-Flow an, der die Protokolle definiert, die ein ID-Token ausgeben.