cuplook.a2-school.edu.pl

Azure sts token

Übersicht über Token in Azure Active Directory B2C

Azure Active Directory B2C (Azure AD B2C) gibt bei der Verarbeitung der einzelnen Authentifizierungsabläufe verschiedene Arten von Sicherheitstoken aus. In diesem Artikel werden das Format, die Sicherheitsmerkmale und der Inhalt der einzelnen Tokentypen beschrieben.

Tokentypen

Azure AD B2C unterstützt die Protokolle OAuth 2.0 und OpenID Connect, bei denen Token für die Authentifizierung und den sicheren Zugriff auf Ressourcen verwendet werden. Bei allen Token, die in Azure AD B2C verwendet werden, handelt es sich um JSON-Webtoken (JWTs), die Assertionen von Informationen über den Bearer und den Betreff des Tokens enthalten.

Die folgenden Token werden bei der Kommunikation mit Azure AD B2C verwendet:

  • ID-Token : Ein JWT-Token, das Ansprüche enthält, die Sie zum Identifizieren von Benutzern in Ihrer Anwendung verwenden können. Dieses Token wird sicher in HTTP-Anforderungen für die Kommunikation zwischen zwei gesendet. Komponenten derselben Anwendung oder desselben Diensts. Sie können die Ansprüche in einem ID-Token nach Belieben verwenden. Sie werden häufig verwendet, um Kontoinformationen anzuzeigen oder Entscheidungen über die Zugriffssteuerung in einer Anwendung zu treffen. Die von Azure AD B2C ausgestellten ID-Token sind signiert, aber nicht verschlüsselt. Wenn Ihre Anwendung oder API ein ID-Token empfängt, muss sie die Signatur validieren, um zu beweisen, dass das Token authentisch ist. Ihre Anwendung oder API muss auch einige Ansprüche im Token überprüfen, um zu beweisen, dass es gültig ist. Abhängig von den Anforderungen des Szenarios können die Ansprüche, die von einer Anwendung überprüft werden, variieren, aber die Anwendung muss in jedem Szenario einige allgemeine Anspruchsüberprüfungen durchführen.

  • Zugriffstoken : Ein JWT, das Ansprüche enthält, die Sie verwenden können, um die erteilten Berechtigungen für Ihre APIs zu identifizieren. Zugriffstoken werden signiert, aber nicht verschlüsselt. Zugriffstoken werden verwendet, um den Zugriff auf APIs und Ressourcenserver. Wenn Ihre API ein Zugriffstoken empfängt, muss sie die Signatur validieren, um zu beweisen, dass das Token authentisch ist. Ihre API muss auch einige Ansprüche im Token überprüfen, um zu beweisen, dass es gültig ist. Abhängig von den Anforderungen des Szenarios können die Ansprüche, die von einer Anwendung überprüft werden, variieren, aber die Anwendung muss in jedem Szenario einige allgemeine Anspruchsüberprüfungen durchführen.

  • Aktualisierungstoken : Aktualisierungstoken werden verwendet, um neue ID-Token und Zugriffstoken in einem OAuth 2.0-Flow abzurufen. Sie bieten Ihrer Anwendung langfristigen Zugriff auf Ressourcen im Namen von Benutzern, ohne dass eine Interaktion mit diesen Benutzern erforderlich ist. Aktualisierungstoken sind für Ihre Anwendung nicht transparent. Sie werden von Azure AD B2C ausgestellt und können nur von Azure AD B2C überprüft und interpretiert werden. Sie sind langlebig, aber Ihre Anwendung sollte nicht mit der Erwartung geschrieben werden, dass ein Aktualisierungstoken für einen bestimmten Zeitraum von Zeit. Aktualisierungstoken können jederzeit aus verschiedenen Gründen ungültig gemacht werden. Die einzige Möglichkeit für Ihre Anwendung, zu ermitteln, ob ein Aktualisierungstoken gültig ist, besteht darin, zu versuchen, es einzulösen, indem Sie eine Tokenanforderung an Azure AD B2C senden. Wenn Sie ein Aktualisierungstoken für ein neues Token einlösen, erhalten Sie ein neues Aktualisierungstoken in der Tokenantwort. Speichern Sie das neue Aktualisierungstoken. Es ersetzt das Aktualisierungstoken, das Sie zuvor in der Anforderung verwendet haben. Mit dieser Aktion wird sichergestellt, dass Ihre Aktualisierungstoken so lange wie möglich gültig bleiben. Single-Page-Anwendungen, die den Autorisierungscodeflow mit PKCE verwenden, haben immer eine Aktualisierungstokenlebensdauer von 24 Stunden. Erfahren Sie mehr über die Auswirkungen von Aktualisierungstoken im Browser auf die Sicherheit.

Endpunkte

Eine registrierte Anwendung empfängt Token und kommuniziert mit Azure AD B2C, indem sie Anforderungen an die folgenden Endpunkte sendet:

Sicherheitstoken, die Ihr Anwendungsempfänge von Azure AD B2C können von den oder-Endpunkten stammen. Wenn ID-Token vom Endpunkt ":" abgerufen werden

  • , erfolgt dies mithilfe des impliziten AblaufsWenn Ihre App jedoch MSAL.js 2.0 oder höher verwendet, aktivieren Sie die Gewährung des impliziten Flusses nicht in Ihrer App-Registrierung, da MSAL.js 2.0+ den Autorisierungscodefluss mit PKCE unterstützt.
  • Endpunkt erfolgt dies mithilfe des Autorisierungscodeflows, der das Token vor dem Browser verborgen hält.

Ansprüche

Wenn Sie Azure AD B2C verwenden, verfügen Sie über eine differenzierte Kontrolle über den Inhalt Ihrer Token. Sie können Benutzerflows und benutzerdefinierte Richtlinien konfigurieren, um bestimmte Sätze von Benutzerdaten in Ansprüchen zu senden, die für Ihre Anwendung erforderlich sind. Diese Ansprüche können Standardeigenschaften wie displayName und emailAddress enthalten. Ihre Anwendungen können diese Ansprüche verwenden, um Benutzer sicher zu authentifizieren und Aufforderungen.

Die Ansprüche in ID-Token werden nicht in einer bestimmten Reihenfolge zurückgegeben. Neue Ansprüche können jederzeit in ID-Token eingeführt werden. Ihre Anwendung sollte nicht unterbrochen werden, wenn neue Ansprüche eingeführt werden. Sie können auch benutzerdefinierte Benutzerattribute in Ihre Ansprüche einschließen.

In der folgenden Tabelle sind die Ansprüche aufgeführt, die Sie in ID-Token und Zugriffstoken erwarten können, die von Azure AD B2C ausgestellt werden.

Name Claim Beispielwert Beschreibung
Zielgruppe Identifiziert den beabsichtigten Empfänger des Tokens. Für Azure AD B2C ist die Zielgruppe die Anwendungs-ID. Ihre Anwendung sollte diesen Wert überprüfen und das Token ablehnen, wenn es nicht übereinstimmt. Publikum ist gleichbedeutend mit Ressource.
Aussteller Identifiziert den Security Token Service (STS), der erstellt das Token und gibt es zurück. Es identifiziert auch das Verzeichnis, in dem der Benutzer authentifiziert wurde. Ihre Anwendung sollte den Ausstelleranspruch überprüfen, um sicherzustellen, dass das Token vom entsprechenden Endpunkt stammt.
Ausgestellt zu Der Zeitpunkt, zu dem der Token ausgegeben wurde, dargestellt in der Epochenzeit.
Ablaufzeit Der Zeitpunkt, zu dem das Token ungültig wird, dargestellt in der Epochenzeit. Ihre Anwendung sollte diesen Anspruch verwenden, um die Gültigkeit der Tokenlebensdauer zu überprüfen.
Nicht vor dem Zeitpunkt, zu dem das Token gültig wird, dargestellt in der Epochenzeit. Dieser Zeitpunkt entspricht in der Regel dem Zeitpunkt, zu dem der Token ausgegeben wurde. Ihre Anwendung sollte diesen Anspruch verwenden, um die Gültigkeit der Tokenlebensdauer zu überprüfen.
Version Die Version des ID-Tokens, wie definiert von Azure AD B2C.
Code-Hash Ein Code-Hash, der nur dann in einem ID-Token enthalten ist, wenn das Token zusammen mit einem OAuth 2.0-Autorisierungscode ausgestellt wird. Ein Code-Hash kann verwendet werden, um die Authentizität eines Autorisierungscodes zu überprüfen. Weitere Informationen zum Durchführen dieser Validierung finden Sie in der OpenID Connect-Spezifikation.
Zugriffstoken-Hash Ein Zugriffstoken-Hash, der nur dann in einem ID-Token enthalten ist, wenn das Token zusammen mit einem OAuth 2.0-Zugriffstoken ausgestellt wird. Ein Zugriffstoken-Hash kann verwendet werden, um die Authentizität eines Zugriffstokens zu überprüfen. Weitere Informationen zum Durchführen dieser Validierung finden Sie in der OpenID Connect-Spezifikation
Nonce Eine Nonce ist eine Strategie zur Abwehr von Token-Replay-Angriffen. Die Anwendung kann mithilfe des Abfrageparameters eine Nonce in einer Autorisierungsanforderung angeben. Das Der Wert, den Sie in der Anforderung angeben, wird nur im Anspruch eines ID-Tokens unverändert ausgegeben. Dieser Anspruch ermöglicht es der Anwendung, den Wert anhand des in der Anforderung angegebenen Werts zu überprüfen. Ihre Anwendung sollte diese Überprüfung während des ID-Token-Überprüfungsprozesses durchführen.
Subject Der Prinzipal, über den das Token Informationen bestätigt, z. B. den Benutzer einer Anwendung. Dieser Wert ist unveränderlich und kann nicht neu zugewiesen oder wiederverwendet werden. Es kann verwendet werden, um Autorisierungsüberprüfungen sicher durchzuführen, z. B. wenn das Token für den Zugriff auf eine Ressource verwendet wird. Standardmäßig wird der Betreffanspruch mit der Objekt-ID des Benutzers im Verzeichnis aufgefüllt.
Referenz zur Authentifizierungskontextklasse Nicht zutreffend Wird nur mit älteren Richtlinien verwendet.
Richtlinie für das Vertrauensframework Der Name der Richtlinie, die verwendet wurde , um das ID-Token abzurufen.
Authentifizierungszeit Der Zeitpunkt, zu dem ein Benutzer zuletzt Anmeldeinformationen eingegeben hat, angegeben in Epochenzeit. Es gibt keinen Unterschied zwischen einer neuen Anmeldung, einer SSO-Sitzung (Single Sign-On) oder einem anderen Anmeldetyp. Dies ist das letzte Mal, dass die Anwendung (oder der Benutzer) einen Authentifizierungsversuch für Azure AD B2C initiiert hat. Die Methode, die für die Authentifizierung verwendet wird, ist nicht differenziert.
Bereich Die Berechtigungen, die der Ressource für ein Zugriffstoken erteilt wurden. Mehrere erteilte Berechtigungen werden durch ein Leerzeichen getrennt.
Autorisierte Partei Die Anwendungs-ID der Clientanwendung, die die Anforderung initiiert hat.

Konfiguration

Die folgenden Eigenschaften werden verwendet, um die Lebensdauer von Von Azure AD B2C ausgegebene Sicherheitstoken:

  • Lebensdauer von Zugriffs- und ID-Token (Minuten): Die Lebensdauer des OAuth 2.0-Bearertokens, das für den Zugriff auf eine geschützte Ressource verwendet wird. Der Standardwert ist 60 Minuten. Das Minimum (einschließlich) beträgt 5 Minuten. Die Höchstdauer (einschließlich) beträgt 1440 Minuten.

  • Lebensdauer des Aktualisierungstokens (Tage): Der maximale Zeitraum, vor dem ein Aktualisierungstoken zum Abrufen eines neuen Zugriffs- oder ID-Tokens verwendet werden kann. Der Zeitraum umfasst auch das Abrufen eines neuen Aktualisierungstokens, wenn Ihrer Anwendung der Bereich gewährt wurde. Der Standardwert beträgt 14 Tage. Der Mindestbetrag (inklusive) beträgt einen Tag. Die Höchstdauer (einschließlich) beträgt 90 Tage.

  • Lebensdauer des gleitenden Zeitfensters des Aktualisierungstokens (Tage) – Nach Ablauf dieses Zeitraums ist der Benutzer gezwungen, sich erneut zu authentifizieren, unabhängig von der Gültigkeitsdauer der meisten Letztes Aktualisierungstoken, das von der Anwendung abgerufen wurde. Er kann nur bereitgestellt werden, wenn der Schalter auf Begrenzt gesetzt ist. Er muss größer oder gleich dem Wert für die Lebensdauer des Aktualisierungstokens (Tage) sein. Wenn der Schalter auf Kein Ablauf festgelegt ist, können Sie keinen bestimmten Wert angeben. Der Standardwert ist 90 Tage. Der Mindestbetrag (inklusive) beträgt einen Tag. Das Maximum (einschließlich) beträgt 365 Tage.

Die folgenden Anwendungsfälle werden mit diesen Eigenschaften aktiviert:

  • Erlauben Sie einem Benutzer, auf unbestimmte Zeit bei einer mobilen Anwendung angemeldet zu bleiben, solange der Benutzer in der Anwendung kontinuierlich aktiv ist. Sie können die Lebensdauer des gleitenden Fensters für Aktualisierungstoken (Tage) in Ihrem Anmeldebenutzerflow auf Kein Ablauf festlegen.
  • Erfüllen Sie die Sicherheits- und Complianceanforderungen Ihrer Branche, indem Sie das entsprechende Zugriffstoken festlegen Lebzeiten.

Diese Einstellungen sind für Benutzerflows zum Zurücksetzen des Kennworts nicht verfügbar.

Kompatibilität

Die folgenden Eigenschaften werden zum Verwalten der Tokenkompatibilität verwendet:

  • Ausstelleranspruch (iss): Diese Eigenschaft identifiziert den Azure AD B2C-Mandanten, der das Token ausgestellt hat. Der Standardwert ist . Der Wert von enthält IDs sowohl für den Azure AD B2C-Mandanten als auch für den Benutzerflow, der in der Tokenanforderung verwendet wurde. Wenn Ihre Anwendung oder Bibliothek Azure AD B2C benötigt, um mit der OpenID Connect Discovery 1.0-Spezifikation kompatibel zu sein, verwenden Sie diesen Wert.

  • Subject (sub) claim – Diese Eigenschaft identifiziert die Entität, für die das Token Informationen bestätigt. Der Standardwert ist ObjectID , der den Anspruch im Token mit der Objekt-ID des Benutzers auffüllt. Der Wert von Nicht unterstützt wird nur aus Gründen der Abwärtskompatibilität bereitgestellt. Es wird empfohlen, so bald wie möglich zu ObjectID zu wechseln.

  • Anspruch, der die Richtlinien-ID darstellt : Diese Eigenschaft identifiziert den Anspruchstyp, in den der in der Tokenanforderung verwendete Richtlinienname eingefügt wird. Der Standardwert ist . Der Wert von wird nur aus Gründen der Abwärtskompatibilität angegeben.

Wenn

eine User Journey gestartet wird, erhält Azure AD B2C ein Zugriffstoken von einem Identitätsanbieter. Azure AD B2C verwendet dieses Token, um Informationen über den Benutzer abzurufen. Sie aktivieren einen Anspruch in Ihrem Benutzerflow, um das Token an die Anwendungen zu übergeben, die Sie in Azure AD B2C registrieren. Ihre Anwendung muss einen empfohlenen Benutzerflow verwenden, um die Übergabe des Tokens als Anspruch nutzen zu können.

Azure AD B2C unterstützt derzeit nur die Übergabe der Zugriffstoken von OAuth 2.0-Identitätsanbietern, zu denen Facebook und Google gehören. Bei allen anderen Identitätsanbietern wird der Anspruch leer zurückgegeben.

Validierung

Um ein Token zu validieren, sollte die Anwendung sowohl die Signatur als auch die Ansprüche des Tokens überprüfen. Für die Validierung von JWTs stehen je nach bevorzugter Sprache viele Open-Source-Bibliotheken zur Verfügung. Es wird empfohlen, diese Optionen zu erkunden, anstatt eine eigene Validierungslogik zu implementieren.

Signatur validieren

Ein JWT besteht aus drei Segmenten, einem Header , einem Body und einer Signatur . Das Signatursegment kann verwendet werden, um die Authentizität des Tokens zu validieren, damit es von Ihrer Anwendung als vertrauenswürdig eingestuft werden kann. Azure AD B2C-Token werden mithilfe von asymmetrischen Verschlüsselungsalgorithmen nach Branchenstandard signiert, z. B. RSA 256.

Der Header des Tokens enthält Informationen über der Schlüssel und die Verschlüsselungsmethode, die zum Signieren des Tokens verwendet werden:

Der Wert des alg-Anspruchs ist der Algorithmus, der zum Signieren des Tokens verwendet wurde. Der Wert des kid-Anspruchs ist der öffentliche Schlüssel, der zum Signieren des Tokens verwendet wurde. Azure AD B2C kann jederzeit ein Token signieren, indem es eines aus einer Reihe von öffentlich-privaten Schlüsselpaaren verwendet. Azure AD B2C rotiert den möglichen Satz von Schlüsseln regelmäßig. Die Anwendung sollte so geschrieben werden, dass sie diese Schlüsseländerungen automatisch verarbeitet. Eine angemessene Häufigkeit, um nach Updates für die von Azure AD B2C verwendeten öffentlichen Schlüssel zu suchen, ist alle 24 Stunden. Um unerwartete Schlüsseländerungen zu behandeln, sollte die Anwendung so geschrieben werden, dass sie die öffentlichen Schlüssel erneut abruft, wenn sie einen unerwarteten untergeordneten Wert empfängt.

Azure AD B2C verfügt über einen OpenID Connect-Metadatenendpunkt. Mit diesem Endpunkt können Anwendungen zur Laufzeit Informationen zu Azure AD B2C anfordern. Das Zu den Informationen gehören Endpunkte, Tokeninhalte und Tokensignaturschlüssel. Ihr Azure AD B2C-Mandant enthält ein JSON-Metadatendokument für jede Richtlinie. Das Metadatendokument ist ein JSON-Objekt, das mehrere nützliche Informationen enthält. Die Metadaten enthalten jwks_uri , der den Speicherort des Satzes öffentlicher Schlüssel angibt, die zum Signieren von Token verwendet werden. Dieser Speicherort wird hier angegeben, aber es empfiehlt sich, den Speicherort dynamisch abzurufen, indem Sie das Metadatendokument verwenden und jwks_uri analysieren:

Das JSON-Dokument, das sich unter dieser URL befindet, enthält alle Informationen zum öffentlichen Schlüssel, die zu einem bestimmten Zeitpunkt verwendet werden. Ihre App kann den Anspruch im JWT-Header verwenden, um den öffentlichen Schlüssel im JSON-Dokument auszuwählen, der zum Signieren eines bestimmten Tokens verwendet wird. Es kann dann eine Signaturvalidierung durchführen, indem es den richtigen öffentlichen Schlüssel und den angegebenen Algorithmus verwendet.

Das Metadatendokument für die Richtlinie in Der Mandant befindet sich unter:

Um zu bestimmen, welche Richtlinie zum Signieren eines Tokens verwendet wurde (und wo die Metadaten angefordert werden sollen), haben Sie zwei Möglichkeiten. Zunächst wird der Richtlinienname in den (Standard) oder den Anspruch (wie konfiguriert) im Token aufgenommen. Sie können Ansprüche aus dem Text des JWT analysieren, indem Sie den Text mit Base-64 decodieren und die resultierende JSON-Zeichenfolge deserialisieren. Der oder-Anspruch ist der Name der Richtlinie, die zum Ausstellen des Tokens verwendet wurde. Die andere Möglichkeit besteht darin, die Richtlinie beim Ausgeben der Anforderung im Wert des Parameters zu codieren und dann zu decodieren, um zu bestimmen, welche Richtlinie verwendet wurde. Beide Methoden sind gültig.

Azure AD B2C verwendet den RS256-Algorithmus, der auf der RFC 3447-Spezifikation basiert. Der öffentliche Schlüssel besteht aus zwei Komponenten: dem RSA-Modul () und dem öffentlichen RSA-Exponenten (). Sie können Werte für die Tokenüberprüfung programmgesteuert in ein Zertifikatformat konvertieren.

Eine Beschreibung, wie man Die Signaturvalidierung durchführen liegt außerhalb des Rahmens dieses Dokuments. Es stehen viele Open-Source-Bibliotheken zur Verfügung, mit denen Sie ein Token validieren können.

Überprüfen von Ansprüchen

Wenn Ihre Anwendung oder API ein ID-Token empfängt, sollte sie auch mehrere Überprüfungen für die Ansprüche im ID-Token durchführen. Die folgenden Ansprüche sollten überprüft werden:

  • audience – Überprüft, ob das ID-Token für Ihre Anwendung bereitgestellt werden sollte.
  • nicht vor und Ablaufzeit: Überprüft, ob das ID-Token nicht abgelaufen ist.
  • issuer : Überprüft, ob das Token von Azure AD B2C für Ihre Anwendung ausgestellt wurde.
  • nonce – Eine Strategie zur Abwehr von Token-Replay-Angriffen.

Eine vollständige Liste der Validierungen, die Ihre Anwendung durchführen sollte, finden Sie in der OpenID Connect-Spezifikation.

Nächste Schritte

Erfahren Sie mehr über die Verwendung von Zugriffstoken.