Freigeben über

Konfigurieren von Token in Azure Active Directory B2C

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

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.

Lebensdauer 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:

  1. Melden Sie sich beim Azure-Portal an.
  2. 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.
  3. 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.
  4. Wählen Sie Benutzerflows (Richtlinien) aus.
  5. Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.
  6. Wählen Sie Eigenschaften aus.
  7. Passen Sie unter Tokenlebensdauer die Eigenschaften an die Anforderungen Ihrer Anwendung an.
  8. Wählen Sie Speichern aus.

Konfigurieren Sie Benutzerflow-Token im Azure-Portal.

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 auf truefest.
  • 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) oder acr.

So konfigurieren Sie die Kompatibilitätseinstellungen für Benutzerflows:

  1. Wählen Sie Benutzerflows (Richtlinien) aus.
  2. Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.
  3. Wählen Sie Eigenschaften aus.
  4. Passen Sie unter Tokenkompatibilitätseinstellungen die Eigenschaften an die Anforderungen Ihrer Anwendung an.
  5. 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) und ACR (Authentifizierungskontextreferenz). TFP ist der empfohlene Wert. Legen Sie AuthenticationContextReferenceClaimPattern mit dem Wert fest None.

    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 Supportedmö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.

  1. Wählen Sie Benutzerflows (Richtlinien) aus.
  2. Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.
  3. Wählen Sie "Anwendungsansprüche" aus.
  4. Wählen Sie die Ansprüche und Attribute aus, die Sie an die Anwendung zurücksenden möchten.
  5. 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.

  1. Öffnen Sie Ihre benutzerdefinierte Richtliniendatei. Beispiel: SignUpOrSignin.xml.
  2. Suchen Sie das OutputClaims-Element. Fügen Sie den OutputClaim hinzu, der in das Token aufgenommen werden soll.
  3. 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