Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
Ab dem 1. Mai 2025 steht Azure AD B2C nicht mehr für neue Kunden zur Verfügung. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen.
Bevor Sie beginnen, verwenden Sie die Auswahl eines Richtlinientyps oben auf dieser Seite, um den Typ der Richtlinie auszuwählen, die Sie einrichten. Azure Active Directory B2C bietet zwei Methoden zum Definieren der Benutzerinteraktion mit Ihren Anwendungen: vordefinierte Benutzerflows oder vollständig konfigurierbare benutzerdefinierte Richtlinien. Die Schritte, die in diesem Artikel erforderlich sind, unterscheiden sich für jede Methode.
In diesem Artikel erfahren Sie, wie Sie die Lebensdauer und Kompatibilität eines Tokens in Azure Active Directory B2C (Azure AD B2C) konfigurieren.
Voraussetzungen
- Erstellen Sie einen Benutzerflow, damit sich Benutzer bei Ihrer Anwendung registrieren und anmelden können.
- Registrieren Sie eine Webanwendung.
- Führen Sie die Schritte in "Erste Schritte mit benutzerdefinierten Richtlinien in Active Directory B2C" aus. In diesem Lernprogramm erfahren Sie, wie Sie benutzerdefinierte Richtliniendateien für die Verwendung Ihrer Azure AD B2C-Mandantenkonfiguration aktualisieren.
- Registrieren Sie eine Webanwendung.
Verhalten der Tokenlebensdauer
Sie können die Tokenlebensdauer konfigurieren, einschließlich:
- Lebensdauer von Zugriffs- und ID-Token (Minuten) – Die Lebensdauer des OAuth 2.0-Bearertokens und der ID-Token. Der Standardwert ist 60 Minuten (1 Stunde). Der Mindestwert ist fünf Minuten (einschließlich). Das Maximum (einschließlich) beträgt 1.440 Minuten (24 Stunden).
-
Lebensdauer des Aktualisierungstokens (Tage): Der maximale Zeitraum, vor dem ein Aktualisierungstoken zum Abrufen eines neuen Zugriffstokens verwendet werden kann, wenn Ihrer Anwendung der
offline_access
Bereich gewährt wurde. Der Standardwert ist 14 Tage. Das Minimum (inklusive) ist ein Tag. Die maximale (einschließlich) 90 Tage. -
Lebensdauer des gleitenden Fensters des Aktualisierungstokens : Der Typ des gleitenden Fensters des Aktualisierungstokens.
Bounded
Gibt an, dass das Aktualisierungstoken wie in der Lebensdauerlänge (Tage) angegeben erweitert werden kann.No expiry
Gibt an, dass die Lebensdauer des gleitenden Fensters des Aktualisierungstokens nie abläuft. - Lebensdauer (Tage): Nach Ablauf dieses Zeitraums wird der Benutzer gezwungen, sich erneut zu authentifizieren, unabhängig von der Gültigkeitsdauer des letzten Aktualisierungstokens, das von der Anwendung abgerufen wurde. Der Wert muss größer oder gleich dem Wert für die Lebensdauer des Aktualisierungstokens sein.
Das folgende Diagramm zeigt das Verhalten der Lebensdauer des gleitenden Fensters des Aktualisierungstokens.
Hinweis
Single-Page-Anwendungen, die den Autorisierungscodeflow mit PKCE verwenden, haben immer eine Lebensdauer des Aktualisierungstokens von 24 Stunden, während für mobile Apps, Desktop-Apps und Web-Apps diese Einschränkung nicht gilt. Erfahren Sie mehr über die Sicherheitsauswirkungen von Aktualisierungstoken im Browser.
Konfigurieren der Tokenlebensdauer
So konfigurieren Sie die Lebensdauer Ihres Benutzerflow-Tokens:
- Melden Sie sich beim Azure-Portal an.
- Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben aus, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C-Mandanten zu wechseln.
- Wählen Sie "Alle Dienste " in der oberen linken Ecke des Azure-Portals aus, und suchen Sie dann nach Azure AD B2C, und wählen Sie sie aus.
- Wählen Sie Benutzerflows (Richtlinien) aus.
- Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.
- Wählen Sie Eigenschaften aus.
- Passen Sie unter Tokenlebensdauer die Eigenschaften an die Anforderungen Ihrer Anwendung an.
- Wählen Sie Speichern aus.
Um die Einstellungen für die Tokenkompatibilität zu ändern, legen Sie die Metadaten des technischen Profils des Tokenausstellers in der Erweiterung oder in der Datei der vertrauenden Seite der Richtlinie fest, auf die Sie sich auswirken möchten. Das technische Profil des Tokenausstellers sieht wie im folgenden Beispiel aus:
<ClaimsProviders>
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="JwtIssuer">
<Metadata>
<Item Key="token_lifetime_secs">3600</Item>
<Item Key="id_token_lifetime_secs">3600</Item>
<Item Key="refresh_token_lifetime_secs">1209600</Item>
<Item Key="rolling_refresh_token_lifetime_secs">7776000</Item>
<!--<Item Key="allow_infinite_rolling_refresh_token">true</Item>-->
<Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>
<Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
</Metadata>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
</ClaimsProviders>
Im vorherigen Beispiel wurden die folgenden Werte festgelegt:
- token_lifetime_secs – Lebensdauer des Zugriffstokens (Sekunden). Der Standardwert ist 3.600 (1 Stunde). Das Minimum beträgt 300 (5 Minuten). Das Maximum liegt bei 86.400 (24 Stunden).
- id_token_lifetime_secs - Lebensdauer von ID-Token (Sekunden). Der Standardwert ist 3.600 (1 Stunde). Das Minimum beträgt 300 (5 Minuten). Das Maximum liegt bei 86.400 (24 Stunden).
- refresh_token_lifetime_secs Gültigkeitsdauer von Aktualisierungstoken (Sekunden). Der Standardwert ist 1.209.600 (14 Tage). Das Minimum ist 86.400 (24 Stunden). Das Maximum beträgt 7.776.000 (90 Tage).
-
rolling_refresh_token_lifetime_secs – Lebensdauer des gleitenden Fensters des Aktualisierungstokens (Sekunden). Der Standardwert ist 7.776.000 (90 Tage). Das Minimum ist 86.400 (24 Stunden). Das Maximum liegt bei 31.536.000 (365 Tage). Wenn Sie die Lebensdauer eines gleitenden Fensters nicht erzwingen möchten, legen Sie den Wert von
allow_infinite_rolling_refresh_token
auftrue
fest. - allow_infinite_rolling_refresh_token – Die Lebensdauer des gleitenden Fensters des Aktualisierungstokens läuft nie ab.
Tokenkompatibilitätseinstellungen
Sie können die Tokenkompatibilität konfigurieren, einschließlich:
- Issuer (iss)-Anspruch : Das Format des Zugriffs- und ID-Tokenausstellers.
- Subjektanspruch (Unteranspruch): Der Prinzipal, über den das Token Informationen bestätigt, z. B. den Benutzer einer Anwendung. Dieser Wert ist unveränderlich und kann nicht erneut zugewiesen oder wiederverwendet werden. Es kann verwendet werden, um Autorisierungsprüfungen sicher durchzuführen, z. B. wenn das Token für den Zugriff auf eine Ressource verwendet wird. Der Anspruch „Antragsteller“ wird standardmäßig mit der Objekt-ID des Benutzers im Verzeichnis aufgefüllt.
-
Anspruch, der den Benutzerflow darstellt : Dieser Anspruch identifiziert den Benutzerflow, der ausgeführt wurde. Mögliche Werte:
tfp
(Standard) oderacr
.
So konfigurieren Sie die Kompatibilitätseinstellungen für Benutzerflows:
- Wählen Sie Benutzerflows (Richtlinien) aus.
- Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.
- Wählen Sie Eigenschaften aus.
- Passen Sie unter Tokenkompatibilitätseinstellungen die Eigenschaften an die Anforderungen Ihrer Anwendung an.
- Wählen Sie Speichern aus.
Um die Einstellungen für die Tokenkompatibilität zu ändern, legen Sie die Metadaten des technischen Profils des Tokenausstellers in der Erweiterung oder in der Datei der vertrauenden Seite der Richtlinie fest, die Sie aktualisieren möchten. Das technische Profil des Tokenausstellers sieht wie im folgenden Beispiel aus:
<ClaimsProviders>
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="JwtIssuer">
<Metadata>
...
<Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>
<Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
</Metadata>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
</ClaimsProviders>
Issuer (iss)-Anspruch : Der Issuer-Anspruch (iss) wird mit dem IssuanceClaimPattern-Metadatenelement festgelegt. Die anwendbaren Werte sind
AuthorityAndTenantGuid
und .AuthorityWithTfp
Festlegen eines Anspruchs, der die Richtlinien-ID darstellt: Die Optionen zum Festlegen dieses Werts sind
TFP
(Trust Framework-Richtlinie) undACR
(Authentifizierungskontextreferenz).TFP
ist der empfohlene Wert. Legen Sie AuthenticationContextReferenceClaimPattern mit dem Wert festNone
.Fügen Sie im ClaimsSchema-Element das folgende Element hinzu:
<ClaimType Id="trustFrameworkPolicy"> <DisplayName>Trust framework policy name</DisplayName> <DataType>string</DataType> </ClaimType>
Fügen Sie in der Richtlinie der vertrauenden Seite unter dem OutputClaims-Element den folgenden Ausgabeanspruch hinzu:
<OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" PartnerClaimType="tfp" />
Entfernen Sie für ACR das AuthenticationContextReferenceClaimPattern-Element .
Subject (sub) claim - Diese Option ist standardmäßig auf ObjectID festgelegt. Wenn Sie diese Einstellung ändern
Not Supported
möchten, ersetzen Sie diese Zeile:<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub" />
Durch diese Zeile:
<OutputClaim ClaimTypeReferenceId="sub" />
Bereitstellen optionaler Ansprüche für Ihre App
Die Anwendungsansprüche sind Werte, die an die Anwendung zurückgegeben werden. Aktualisieren Sie Ihren Benutzerflow so, dass er die gewünschten Ansprüche enthält.
- Wählen Sie Benutzerflows (Richtlinien) aus.
- Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.
- Wählen Sie "Anwendungsansprüche" aus.
- Wählen Sie die Ansprüche und Attribute aus, die Sie an die Anwendung zurücksenden möchten.
- Wählen Sie Speichern aus.
Die Ausgabeansprüche für das technische Profil der Richtlinie der vertrauenden Seite sind Werte, die an eine Anwendung zurückgegeben werden. Durch das Hinzufügen von Ausgabeansprüchen werden die Ansprüche nach einer erfolgreichen User Journey im Token ausgegeben und an die Anwendung gesendet. Ändern Sie das technische Profilelement im Abschnitt der vertrauenden Seite, um die gewünschten Ansprüche als Ausgabeanspruch hinzuzufügen.
- Öffnen Sie Ihre benutzerdefinierte Richtliniendatei. Beispiel: SignUpOrSignin.xml.
- Suchen Sie das OutputClaims-Element. Fügen Sie den OutputClaim hinzu, der in das Token aufgenommen werden soll.
- Legen Sie die Ausgabeanspruchsattribute fest.
Im folgenden Beispiel wird der accountBalance
Anspruch hinzugefügt. Die Forderung accountSaldo wird als Saldo an die Anwendung gesendet.
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" />
<OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
<!--Add the optional claims here-->
<OutputClaim ClaimTypeReferenceId="accountBalance" DefaultValue="" PartnerClaimType="balance" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
Das OutputClaim-Element enthält die folgenden Attribute:
- ClaimTypeReferenceId : Der Bezeichner eines Anspruchstyps, der bereits im Abschnitt ClaimsSchema in der Richtliniendatei oder der übergeordneten Richtliniendatei definiert ist.
- PartnerClaimType : Ermöglicht es Ihnen, den Namen des Anspruchs im Token zu ändern.
- DefaultValue – Ein Standardwert. Sie können den Standardwert auch auf einen Anspruchskonfliktlöser festlegen, z. B. die Mandanten-ID.
- AlwaysUseDefaultValue : Erzwingt die Verwendung des Standardwerts.
Lebensdauer des Autorisierungscodes
Bei Verwendung des OAuth 2.0-Autorisierungscodeflows kann die App den Autorisierungscode verwenden, um ein Zugriffstoken für eine Zielressource anzufordern. Autorisierungscodes sind kurzlebig und laufen nach etwa 10 Minuten ab. Die Lebensdauer des Autorisierungscodes kann nicht konfiguriert werden. Stellen Sie sicher, dass Ihre Anwendung die Autorisierungscodes innerhalb von 10 Minuten einlöst.
Verwandte Inhalte
- Erfahren Sie mehr darüber, wie Sie Zugriffstoken anfordern.
- Erfahren Sie, wie Sie Resilienz durch bewährte Methoden für Entwickler erstellen.