Konfigurieren von Token in Azure Active Directory B2C

  • Artikel
  • 6 Minuten Lesedauer

Bevor Sie beginnen, verwenden Sie den Auswahlpunkt Richtlinientyp wählen, um die Art der Richtlinie auszuwählen, die Sie einrichten möchten. 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

Tokenlebensdauer und Verhalten

Sie können die Lebens- bzw. Gültigkeitsdauer von Token wie folgt konfigurieren:

  • Lebensdauer von Zugriffs- und ID-Token (Minuten) : Gültigkeitsdauer des OAuth 2.0-Bearertokens und der ID-Token. Der Standardwert beträgt 60 Minuten (1 Stunde). Der Mindestwert ist fünf Minuten (einschließlich). Der Höchstwert beträgt 1.440 Minuten (24 Stunden).
  • Lebensdauer des Aktualisierungstokens (Tage) : Der maximale Zeitraum, in dem ein Aktualisierungstoken zum Anfordern eines neuen Zugriffstokens verwendet werden kann, wenn Ihrer Anwendung der Bereich offline_access erteilt wurde. Der Standardwert ist 14 Tage. Der Mindestwert ist ein Tag (einschließlich). Der Höchstwert beträgt 90 Tage (einschließlich).
  • Lebensdauer für gleitendes Fenster des Aktualisierungstokens: Typ des gleitenden Fensters für das Aktualisierungstoken. Bounded gibt an, dass das Aktualisierungstoken wie unter Lebensdauer (Tage) angegeben verlängert werden kann. No expiry gibt an, dass die Lebensdauer für das gleitende Fenster des Aktualisierungstokens nie abläuft.
  • Lebensdauer (Tage) : Nach Ablauf dieses Zeitraums muss der Benutzer sich erneut authentifizieren, und zwar unabhängig von der Gültigkeitsdauer des zuletzt von der Anwendung erworbenen Aktualisierungstokens. Der Wert muss mindestens dem Wert Lebensdauer des Aktualisierungstokens (Tage) entsprechen oder darüber liegen.

Das folgende Diagramm zeigt das Verhalten der Lebensdauer für das gleitende Fenster des Aktualisierungstokens.

Lebensdauer von Aktualisierungstoken

Hinweis

Bei Single-Page-Webanwendungen, die den Autorisierungscodeflow mit PKCE verwenden, beträgt die Lebensdauer von Aktualisierungstoken immer 24 Stunden. Diese Einschränkung gilt nicht für mobile Apps, Desktop-Apps und Web-Apps. Weitere Informationen zu Sicherheitsaspekten von Aktualisierungstoken im Browser

Konfigurieren der Tokenlebensdauer

So konfigurieren Sie die Tokenlebensdauer für den Benutzerflow

  1. Melden Sie sich beim Azure-Portal an.
  2. Stellen Sie sicher, dass Sie das Verzeichnis verwenden, das Ihren Azure AD B2C-Mandanten enthält. Wählen Sie auf der Symbolleiste des Portals das Symbol Verzeichnisse und Abonnements aus.
  3. Suchen Sie auf der Seite Portaleinstellungen > Verzeichnisse und Abonnements das Azure AD B2C-Verzeichnis in der Liste Verzeichnisname, und klicken Sie dann auf Wechseln.
  4. Wählen Sie links oben im Azure-Portal die Option Alle Dienste aus, suchen Sie nach Azure AD B2C, und wählen Sie dann diese Option aus.
  5. Wählen Sie Benutzerflows (Richtlinien) aus.
  6. Öffnen Sie den Benutzerflow, den Sie zuvor erstellt haben.
  7. Wählen Sie Eigenschaften aus.
  8. Passen Sie unter Tokenlebensdauer die Eigenschaften an die Anforderungen Ihrer Anwendung an.
  9. Wählen Sie Speichern aus.

Konfigurieren von Benutzerflowtoken im Azure-Portal

Um die Einstellungen für die Tokenkompatibilität zu ändern, legen Sie in der Erweiterung die Metadaten des technischen Profils für den Tokenaussteller oder die Datei der vertrauenden Seite der Richtlinie fest, die Sie beeinflussen möchten. Das technische Profil für den Tokenaussteller 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 vorstehenden Beispiel werden die folgenden Werte festgelegt:

  • token_lifetime_secs: Lebensdauer von Zugriffstoken (Sekunden). Der Standardwert beträgt 3.600 Sekunden (1 Stunde). Der Mindestwert beträgt 300 Sekunden (5 Minuten). Der Höchstwert beträgt 86.400 Sekunden (24 Stunden).
  • id_token_lifetime_secs: Lebensdauer von ID-Token (Sekunden). Der Standardwert beträgt 3.600 Sekunden (1 Stunde). Der Mindestwert beträgt 300 Sekunden (5 Minuten). Der Höchstwert beträgt 86.400 Sekunden (24 Stunden).
  • refresh_token_lifetime_secs: Lebensdauer von Aktualisierungstoken (Sekunden). Der Standardwert ist 1.209.600 (14 Tage). Der Mindestwert beträgt 86.400 Sekunden (24 Stunden). Der Höchstwert ist 7,776,000 Tage.
  • rolling_refresh_token_lifetime_secs: Lebensdauer für gleitendes Fenster des Aktualisierungstokens (Sekunden). Der Standardwert beträgt 7.776.000 Sekunden (90 Tage). Der Mindestwert beträgt 86.400 Sekunden (24 Stunden). Der Höchstwert ist 31,536,000 Tage. Wenn Sie keine Lebensdauer für das gleitende Fenster erzwingen möchten, legen Sie den Wert allow_infinite_rolling_refresh_token auf true fest.
  • allow_infinite_rolling_refresh_token: Das gleitende Fenster für Aktualisierungstoken läuft nie ab.

Tokenkompatibilitätseinstellungen

Sie können die Kompatibilität von Token konfigurieren. Dazu zählen auch:

  • Ausstelleranspruch (iss) : Das Format des Ausstellers von Zugriffs- und ID-Token.
  • Antragstelleranspruch (sub) : Der Prinzipal, für den das Token Informationen bestätigt (z. B. Benutzer einer Anwendung). Dieser Wert ist unveränderlich und kann nicht erneut zugewiesen oder wiederverwendet werden. Er kann für die sichere Durchführung von Autorisierungsüberprüfungen verwendet werden, z.B. wenn das Token verwendet wird, um auf eine Ressource zuzugreifen. Der Anspruch „Antragsteller“ wird standardmäßig mit der Objekt-ID des Benutzers im Verzeichnis aufgefüllt.
  • Anspruch für Benutzerflow: Dieser Anspruch identifiziert den ausgeführten Benutzerflow. 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 in der Erweiterung die Metadaten des technischen Profils für den Tokenaussteller oder die Datei der vertrauenden Seite der Richtlinie fest, die Sie aktualisieren möchten. Das technische Profil für den Tokenaussteller 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>

  • Ausstelleranspruch (iss): Der Ausstelleranspruch (iss) wird mit dem Metadatenelement IssuanceClaimPattern festgelegt. Die gültigen Werte sind AuthorityAndTenantGuid und AuthorityWithTfp.

  • Festlegen des Anspruchs zur Darstellung der Richtlinien-ID: Die Optionen zum Festlegen dieses Werts sind TFP (Vertrauensframework-Richtlinie) und ACR (Authentifizierungskontext-Referenz). Der empfohlene Wert ist TFP. Legen Sie für AuthenticationContextReferenceClaimPattern den Wert None fest.

    Fügen Sie im ClaimsSchema-Element dieses Element hinzu:

    <ClaimType Id="trustFrameworkPolicy">
  <DisplayName>Trust framework policy name</DisplayName>
  <DataType>string</DataType>
</ClaimType>

    Fügen Sie in der Richtlinie für die vertrauende Seiteunter dem OutputClaims-Element den folgenden Ausgabeanspruch hinzu:

    <OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" PartnerClaimType="tfp" />

    Entfernen Sie für ACR das Element AuthenticationContextReferenceClaimPattern.

  • Anspruch „Antragsteller“: Diese Option hat standardmäßig den Wert „ObjectID“. Ersetzen Sie die folgende Zeile, um diese Einstellung in Not Supported zu ändern:

    <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 den Benutzerflow, sodass dieser 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 an die Anwendung zurückgesendet werden sollen.
  5. Wählen Sie Speichern aus.

Ausgabeansprüche des technischen Profils der Richtlinie für die vertrauende Seite sind Werte, die an eine Anwendung zurückgegeben werden. Durch Hinzufügen von Ausgabeansprüchen werden die Ansprüche nach einer erfolgreichen User Journey in das Token ausgegeben und an die Anwendung gesendet. Ändern Sie im Abschnitt für die vertrauende Seite das Element des technischen Profils, um die gewünschten Ansprüche als Ausgabeanspruch hinzuzufügen.

  1. Öffnen Sie Ihre benutzerdefinierte Richtliniendatei. Beispiel: SignUpOrSignin.xml.
  2. Suchen Sie nach dem OutputClaims-Element. Fügen Sie den OutputClaim hinzu, den Sie in das Token einschließen möchten.
  3. Legen Sie die Attribute des Ausgabeanspruchs fest.

Im folgenden Beispiel wird der Anspruch accountBalance hinzugefügt. Der Anspruch „accountBalance“ wird als Kontostand 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 ClaimsSchema-Abschnitt der Richtliniendatei oder der übergeordneten Richtliniendatei definiert ist.
  • PartnerClaimType: Ermöglicht Ihnen das Ändern des Namens des Anspruchs im Token.
  • DefaultValue: Ein Standardwert. Sie können den Standardwert auch auf einen Anspruchskonfliktlöser wie die Mandanten-ID festlegen.
  • AlwaysUseDefaultValue: Erzwingt die Verwendung des Standardwerts.

Lebensdauer des Autorisierungscodes

Wenn Sie den OAuth 2.0-Autorisierungscodefluss verwenden, kann die App den Autorisierungscode verwenden, um ein Zugriffstoken für eine Zielressource anzufordern. Autorisierungscodes sind kurzlebig und laufen nach etwa zehn Minuten ab. Die Lebensdauer des Autorisierungscodes kann nicht konfiguriert werden. Stellen Sie sicher, dass Ihre Anwendung die Autorisierungscodes innerhalb von 10 Minuten einlöst.

Nächste Schritte