Anpassen von Ansprüchen, die im JWT-Token (JSON Web Token) für Unternehmensanwendungen ausgestellt wurden

Die Microsoft Identity Platform unterstützt einmaliges Anmelden (Single Sign-On, SSO) mit den meisten vorinstallierten Anwendungen im Microsoft Entra-Anwendungskatalog und benutzerdefinierten Anwendungen. Wenn sich ein Benutzer mithilfe des OIDC-Protokolls über die Microsoft Identity Platform bei einer Anwendung authentifiziert, wird ein Token an die Anwendung gesendet. Die Anwendung überprüft und verwendet das Token, um den Benutzer anzumelden, statt den Benutzernamen und das Kennwort anzufordern.

Diese von OIDC- und OAuth-Anwendungen verwendeten JSON-Webtoken (JWT) enthalten Informationen zum Benutzer, die als Claims bezeichnet werden. Ein Anspruch (Claim) bezeichnet Informationen, die ein Identitätsanbieter über einen Benutzer in dem für diesen Benutzer ausgestellten Token angibt. In einer OIDC-Antwort sind Anspruchsdaten in der Regel im ID-Token enthalten, das vom Identitätsanbieter in Form eines JWT ausgestellt wurde.

Anzeigen oder Bearbeiten von Ansprüchen

Optionale JWT-Ansprüche können in der ursprünglichen Anwendungsregistrierung konfiguriert werden. Sie können jedoch auch in der Unternehmensanwendung konfiguriert werden. So können Sie die im JWT an die Anwendung ausgegebenen Ansprüche anzeigen oder bearbeiten:

1. Melden Sie sich mindestens als Cloudanwendungsadministrator beim Microsoft Entra Admin Center an.
2. Navigieren Sie zu Entra ID>Enterprise-Apps>alle Anwendungen.
3. Wählen Sie die Anwendung aus, wählen Sie "Einmaliges Anmelden" im linken Menü und dann im Abschnitt "Attribute & Claims"die Option "Bearbeiten" aus.

Eine Anwendung kann aus verschiedenen Gründen eine Anpassung von Ansprüchen erfordern. Zum Beispiel, wenn eine Anwendung einen anderen Satz von Anspruchs-URIs oder Anspruchswerten benötigt. Mithilfe des Abschnitts "Attributes & Claims " können Sie einen Anspruch für Ihre Anwendung hinzufügen oder entfernen. Sie können auch einen benutzerdefinierten Anspruch erstellen, der für eine Anwendung basierend auf dem Anwendungsfall spezifisch ist.

Die folgenden Schritte beschreiben, wie Sie einen Konstantenwert zuweisen:

1. Wählen Sie den Anspruch aus, den Sie ändern möchten.
2. Geben Sie den Konstantenwert ohne Anführungszeichen im Source-Attribut gemäß Ihrer Organisation ein, und wählen Sie dann "Speichern" aus.

Die Übersicht Attribute zeigt den konstanten Wert an.

Transformationen besonderer Ansprüche

Sie können die folgenden Funktionen für die Transformation besonderer Ansprüche verwenden:

Hinzufügen anwendungsspezifischer Ansprüche

Gehen Sie wie folgt vor, um anwendungsspezifische Ansprüche hinzuzufügen:

1. Wählen Sie in "Benutzerattribute und Ansprüche" die Option "Neuen Anspruch hinzufügen " aus, um die Seite " Benutzeransprüche verwalten" zu öffnen.
2. Geben Sie den Namen der Ansprüche ein. Der Wert muss nicht unbedingt einem URI-Muster folgen. Wenn Sie ein URI-Muster benötigen, können Sie das in das Namespacefeld einfügen.
3. Wählen Sie die Quelle aus, in der der Anspruch seinen Wert abrufen soll. Sie können ein Benutzerattribut aus der Dropdownliste für „Quellattribut“ auswählen oder eine Transformation auf das Benutzerattribut anwenden, bevor es als Anspruch ausgegeben wird.

Anspruchstransformationen

So wenden Sie eine Transformation auf ein Benutzerattribut an

1. Wählen Sie in "Anspruch verwalten" die Option "Transformation " als Anspruchsquelle aus, um die Seite " Transformation verwalten " zu öffnen.
2. Wählen Sie in der Dropdownliste der Transformationen die Funktion aus. Abhängig von der ausgewählten Funktion müssen Sie Parameter und einen konstanten Wert angeben, die in der Transformation ausgewertet werden sollen.
3. Die Quelle wird als mehrwertige Quelle behandelt, um anzugeben, ob die Transformation auf alle Werte oder nur auf den ersten angewendet wird. Standardmäßig wird die Transformation auf das erste Element in einem mehrwertigen Anspruch angewendet. Wenn Sie dieses Kontrollkästchen aktivieren, wird sichergestellt, dass sie auf alle angewendet wird. Dieses Kontrollkästchen wird nur für mehrwertige Attribute aktiviert. Beispiel: user.proxyaddresses.
4. Wenn Sie mehrere Transformationen anwenden möchten, wählen Sie "Transformation hinzufügen" aus. Sie können maximal zwei Transformationen auf einen Anspruch anwenden. Beispielsweise könnten Sie zuerst das E-Mail-Präfix von user.mailextrahieren. Dann könnten Sie die Zeichenfolge in Großbuchstaben umwandeln.

Zum Transformieren von Ansprüchen können Sie die folgenden Funktionen verwenden.

Wenn Sie andere Transformationen benötigen, übermitteln Sie Ihre Idee im Feedbackforum in der Microsoft Entra-ID unter der SaaS-Anwendungskategorie .

RegEx-basierte Anspruchstransformation

Sie können reguläre Ausdrücke verwenden, um Ansprüche zu transformieren. Bei Verwendung von Regex-basierten Transformationen von Ansprüchen können maximal 20 Regex-Ersetzungen vorgenommen werden.

Die folgende Abbildung zeigt ein Beispiel für die Transformation der ersten Ebene:

Die folgende Tabelle enthält Informationen zur Transformation der ersten Ebene. Die in der Tabelle aufgeführten Aktionen entsprechen den Bezeichnungen in der vorherigen Abbildung. Wählen Sie Bearbeiten aus, um das Blatt für die Anspruchstransformation zu öffnen.

Die folgende Abbildung zeigt ein Beispiel für die Transformation der zweiten Ebene:

Die folgende Tabelle enthält Informationen zur Transformation der zweiten Ebene. Die in der Tabelle aufgeführten Aktionen entsprechen den Bezeichnungen in der vorherigen Abbildung.

Die folgende Abbildung zeigt ein Beispiel zum Testen der Transformationen:

Die folgende Tabelle enthält Informationen zum Testen der Transformationen. Die in der Tabelle aufgeführten Aktionen entsprechen den Bezeichnungen in der vorherigen Abbildung.

Die RegexReplace()-Transformation ist auch für Gruppenanspruchstransformationen verfügbar.

Transformationsüberprüfungen

Eine Meldung enthält weitere Informationen, wenn die folgenden Bedingungen auftreten, nachdem Sie den Test "Hinzufügen " oder "Ausführen" ausgewählt haben:

• Es wurden Eingabeparameter mit doppelten Benutzerattributen verwendet.
• Nicht verwendete Eingabeparameter gefunden. Definierte Eingabeparameter sollten eine entsprechende Verwendung im Text des Ersetzungsmusters aufweisen.
• Die bereitgestellte RegEx-Testeingabe stimmt nicht mit dem angegebenen regulären Ausdruck überein.
• Für die Gruppen im Ersetzungsmuster wurden keine Quellen gefunden.

Ausgeben von Ansprüchen aufgrund von Bedingungen

Sie können die Anspruchsquelle auf Basis des Benutzertyps und der Gruppe, zu der der Benutzer gehört, angeben.

Folgende Benutzertypen stehen zur Auswahl:

• Any – Alle Benutzer dürfen auf die Anwendung zugreifen.
• Mitglieder: Native Mitglieder des Mandanten
• Alle Gäste: Der Benutzer wurde von einer externen Organisation mit oder ohne Microsoft Entra-ID verschoben.
• Microsoft Entra-Gäste: Gastbenutzer gehören zu einer anderen Organisation mit Microsoft Entra ID.
• Externe Gäste: Gastbenutzer gehören zu einer externen Organisation, die keine Microsoft Entra-ID hat.

Der Benutzertyp ist hilfreich bei einem Szenario, bei dem sich die Anspruchsquelle für einen Gast und einen Mitarbeiter, die auf eine Anwendung zugreifen, unterscheidet. Sie können angeben, dass NameID aus „user.email“ erstellt wird, wenn es sich bei dem Benutzer um einen Mitarbeiter handelt. Wenn der Benutzer ein Gast ist, wird NameID aus „user.extensionattribute1“ erstellt.

So fügen Sie eine Anspruchsbedingung hinzu

1. Erweitern Sie in "Anspruch verwalten" die Anspruchsbedingungen.
2. Wählen Sie den Benutzertyp aus.
3. Wählen Sie die Gruppe(n) aus, zu der bzw. denen der Benutzer gehören soll. Sie können übergreifend über alle Ansprüche für eine bestimmte Anwendung bis zu 50 eindeutige Gruppen auswählen.
4. Wählen Sie die Quelle aus, in der der Anspruch seinen Wert abrufen soll. Sie können ein Benutzerattribut aus der Dropdownliste für „Quellattribut“ auswählen oder eine Transformation auf das Benutzerattribut anwenden, bevor es als Anspruch ausgegeben wird.

Die Reihenfolge, in der Sie die Bedingungen hinzufügen, spielt eine wichtige Rolle. Microsoft Entra wertet zuerst alle Bedingungen mit der Quelle Attribute und dann alle Bedingungen mit der Quelle Transformation aus, um zu entscheiden, welcher Wert im Anspruch ausgegeben werden soll. Microsoft Entra ID wertet Bedingungen mit derselben Quelle von oben nach unten aus. Der Anspruch gibt den letzten Wert aus, der mit dem Ausdruck im Anspruch übereinstimmt. Transformationen wie IsNotEmpty und Contains fungieren wie Einschränkungen.

Beispiel: Britta Simon ist Gastbenutzer im Contoso-Mandanten. Britta gehört zu einer anderen Organisation, die ebenfalls Microsoft Entra ID verwendet. Wenn Britta bei der folgenden Konfiguration für die Fabrikam-Anwendung versucht, sich bei Fabrikam anzumelden, wertet Microsoft Identity Platform die Bedingungen aus.

Zunächst überprüft die Microsoft Identity Platform, ob brittas Benutzertyp "Alle Gäste" ist. Da der Typ "Alle Gäste" ist, weist die Microsoft Identity Platform die Quelle für den Anspruch zu user.extensionattribute1. Zweitens überprüft die Microsoft Identity Platform, ob brittas Benutzertyp Microsoft Entra-Gäste ist. Da der Typ "Alle Gäste" ist, weist die Microsoft Identity Platform die Quelle für den Anspruch zu user.mail. Abschließend wird der Anspruch mit dem Wert user.mail für Britta ausgegeben.

Ein weiteres Beispiel: Britta Simon versucht, sich anzumelden, und sie verwendet die folgende Konfiguration. Microsoft Entra wertet zuerst alle Bedingungen mit der Quelle Attribute aus. Die Quelle für den Anspruch ist user.mail, wenn der Benutzertyp von Britta Microsoft Entra-Gäste lautet. Als Nächstes wertet Microsoft Entra ID die Transformationen aus. Da Britta Gast ist, ist user.extensionattribute1 jetzt die neue Quelle für den Anspruch. Da Britta sich in Microsoft Entra-Gäste befindet, ist user.othermail jetzt die neue Quelle für diesen Anspruch. Abschließend wird der Anspruch mit dem Wert user.othermail für Britta ausgegeben.

Als letztes Beispiel betrachten wir, was geschieht, wenn Britta den Wert user.othermail nicht konfiguriert hat oder dieser leer ist. Der Anspruch fällt auf user.extensionattribute1 zurück, wobei der Konditionseintrag in beiden Fällen ignoriert wird.

Sicherheitshinweise

Anwendungen, die Token empfangen, verlassen sich auf Anspruchswerte, die nicht manipuliert werden können. Wenn Sie den Tokeninhalt durch eine Anspruchsanpassung ändern, sind diese Annahmen möglicherweise nicht mehr korrekt. Anwendungen müssen explizit bestätigen, dass Token geändert wurden, um sich vor Anpassungen zu schützen, die von böswilligen Akteuren erstellt wurden. Schützen Sie auf folgende Weise vor unangemessenen Anpassungen:

• Konfigurieren eines benutzerdefinierten Signaturschlüssels
• aktualisieren Sie das Anwendungsmanifest, um zugeordnete Ansprüche zu akzeptieren.

Ohne diesen Wert gibt die Microsoft Entra-ID einen AADSTS50146 Fehlercode zurück.

Konfigurieren eines benutzerdefinierten Signaturschlüssels

Bei mehrinstanzenfähigen Apps sollte ein benutzerdefinierter Signaturschlüssel verwendet werden. Legen Sie acceptMappedClaims nicht im App-Manifest fest. Wenn Sie eine App im Azure-Portal einrichten, erhalten Sie ein App-Registrierungsobjekt und einen Dienstprinzipal in Ihrem Mandanten. Diese App verwendet den globalen Azure-Anmeldeschlüssel, der nicht zum Anpassen von Ansprüchen in Token verwendet werden kann. Um benutzerdefinierte Ansprüche in Token abzurufen, erstellen Sie einen benutzerdefinierten Anmeldeschlüssel aus einem Zertifikat, und fügen Sie ihn dem Dienstprinzipal hinzu. Sie können zu Testzwecken ein selbstsigniertes Zertifikat verwenden. Nachdem Sie den benutzerdefinierten Signaturschlüssel konfiguriert haben, muss Ihr Anwendungscode den Tokensignaturschlüssel überprüfen.

Fügen Sie dem Dienstprinzipal die folgenden Informationen hinzu:

• Privater Schlüssel (als Schlüsselanmeldeinformation)
• Kennwort (als Passwort)
• Öffentlicher Schlüssel (als Schlüsselberechtigung)

Extrahieren Sie den Base64-codierten privaten und öffentlichen Schlüssel aus dem PFX-Dateiexport Ihres Zertifikats. Stellen Sie sicher, dass die für „Sign“ verwendete keyId für keyCredential mit der keyId von passwordCredential übereinstimmt. Sie können customkeyIdentifier generieren, indem Sie den Hash des Zertifikatfingerabdrucks abrufen.

Anforderung

Das folgende Beispiel zeigt das Format der HTTP PATCH-Anforderung zum Hinzufügen eines benutzerdefinierten Signaturschlüssels zu einem Dienstprinzipal. Der Wert „key“ in der keyCredentials-Eigenschaft wird zur besseren Lesbarkeit gekürzt. Der Wert ist Base64-codiert. Für den privaten Schlüssel wird die Eigenschaft Sign verwendet. Für den öffentlichen Schlüssel wird die Eigenschaft Verify verwendet.

PATCH https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222

Content-type: servicePrincipals/json
Authorization: Bearer {token}

{
    "keyCredentials":[
        {
            "customKeyIdentifier": "aB1cD2eF3gH4iJ5kL6-mN7oP8qR=", 
            "endDateTime": "2021-04-22T22:10:13Z",
            "keyId": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333",
            "startDateTime": "2020-04-22T21:50:13Z",
            "type": "X509CertAndPassword",
            "usage": "Sign",
            "key":"cD2eF3gH4iJ5kL6mN7-oP8qR9sT==",
            "displayName": "CN=contoso"
        },
        {
            "customKeyIdentifier": "aB1cD2eF3gH4iJ5kL6-mN7oP8qR=",
            "endDateTime": "2021-04-22T22:10:13Z",
            "keyId": "bbbbbbbb-1c1c-2d2d-3e3e-444444444444",
            "startDateTime": "2020-04-22T21:50:13Z",
            "type": "AsymmetricX509Cert",
            "usage": "Verify",
            "key": "cD2eF3gH4iJ5kL6mN7-oP8qR9sT==",
            "displayName": "CN=contoso"
        }

    ],
    "passwordCredentials": [
        {
            "customKeyIdentifier": "aB1cD2eF3gH4iJ5kL6-mN7oP8qR=",
            "keyId": "cccccccc-2d2d-3e3e-4f4f-555555555555",
            "endDateTime": "2022-01-27T19:40:33Z",
            "startDateTime": "2020-04-20T19:40:33Z",
            "secretText": "mypassword"
        }
    ]
}

Konfigurieren eines benutzerdefinierten Signaturschlüssels mit PowerShell

Verwenden Sie PowerShell, um eine ÖFFENTLICHE MSAL-Clientanwendung zu instanziieren und den Autorisierungscodegenehmigungsfluss zu verwenden, um ein delegiertes Berechtigungszugriffstoken für Microsoft Graph abzurufen. Verwenden Sie das Zugriffstoken, um Microsoft Graph aufzurufen, und konfigurieren Sie einen benutzerdefinierten Signaturschlüssel für den Dienstprinzipal. Nachdem Sie den benutzerdefinierten Signaturschlüssel konfiguriert haben, muss Ihr Anwendungscode den Tokensignaturschlüssel überprüfen.

Sie benötigen folgende Komponenten, um das Skript auszuführen:

• Die Objekt-ID des Dienstprinzipals Ihrer Anwendung, die im Blatt "Übersicht" des Eintrags Ihrer Anwendung in Unternehmensanwendungen im Azure-Portal enthalten ist.
• Eine App-Registrierung zum Anmelden eines Benutzers und Abrufen des Zugriffstokens zum Aufrufen der Microsoft Graph-API. Rufen Sie die Anwendungs-ID (Client-ID) der App im Azure-Portal über das Blatt Übersicht des Eintrags Ihrer Anwendung unter App-Registrierungen ab. Die App-Registrierung sollte die folgende Konfiguration aufweisen:
  • Umleitungs-URI „http://localhost"“, der in der Plattformkonfiguration Mobile Anwendungen und Desktopanwendungen aufgeführt ist
  • In API-Berechtigungen delegierte Microsoft Graph-Berechtigungen Application.ReadWrite.All und User.Read (stellen Sie sicher, dass Sie diesen Berechtigungen Administratorzustimmung erteilen).
• Einen Benutzer, der sich anmeldet, um das Microsoft Graph-Zugriffstoken abzurufen. Der Benutzer oder die Benutzerin muss eine der folgenden Microsoft Entra-Administratorrollen besitzen (zum Aktualisieren des Dienstprinzipals erforderlich):
  • Cloudanwendungsadministrator
  • Anwendungsadministrator
• Ein Zertifikat, das als benutzerdefinierter Signaturschlüssel für unsere Anwendung konfiguriert werden soll. Sie können entweder ein selbstsigniertes Zertifikat erstellen oder eines von Ihrer vertrauenswürdigen Zertifizierungsstelle beziehen. Die folgenden Zertifikatkomponenten werden im Skript verwendet:
  • öffentlicher Schlüssel (in der Regel eine .cer Datei)
  • Privater Schlüssel im PKCS#12-Format (in PFX-Datei )
  • Kennwort für den privaten Schlüssel (PFX-Datei )

##########################################################
# Replace the variables below with the appropriate values 

$fqdn="yourDomainHere" # This is used for the 'issued to' and 'issued by' field of the certificate
$pwd="password" # password for exporting the certificate private key
$tenantId   = "aaaabbbb-0000-cccc-1111-dddd2222eeee" # Replace with your Tenant ID
$appObjId = "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb" # Replace with the Object ID of the App Registration

##########################################################

# Create a self-signed cert

$cert = New-SelfSignedCertificate -certstorelocation cert:\currentuser\my -DnsName $fqdn
$pwdSecure = ConvertTo-SecureString -String $pwd -Force -AsPlainText
$path = 'cert:\currentuser\my\' + $cert.Thumbprint
$location="C:\\temp" # path to folder where both the pfx and cer file will be written to
$cerFile = $location + "\\" + $fqdn + ".cer"
$pfxFile = $location + "\\" + $fqdn + ".pfx"
 
# Export the public and private keys
Export-PfxCertificate -cert $path -FilePath $pfxFile -Password $pwdSecure
Export-Certificate -cert $path -FilePath $cerFile

$pfxpath = $pfxFile # path to pfx file
$cerpath = $cerFile # path to cer file
$password = $pwd  # password for the pfx file
 
# Check PowerShell version (minimum 5.1) (.Net) or PowerShell Core (.Net Core) and read the certificate file accordingly
 
if ($PSVersionTable.PSVersion.Major -gt 5)
    { 
        $core = $true
    }
else
    { 
        $core = $false
    }
 
    #  this is for PowerShell Core
    $Secure_String_Pwd = ConvertTo-SecureString $password -AsPlainText -Force
 
    # reading certificate files and creating Certificate Object
    if ($core)
    {
        $pfx_cert = get-content $pfxpath -AsByteStream -Raw
        $cer_cert = get-content $cerpath -AsByteStream -Raw
        $cert = Get-PfxCertificate -FilePath $pfxpath -Password $Secure_String_Pwd
    }
    else
    {
        $pfx_cert = get-content $pfxpath -Encoding Byte
        $cer_cert = get-content $cerpath -Encoding Byte
        # calling Get-PfxCertificate in PowerShell 5.1 prompts for password - using alternative method
        $cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($pfxpath, $password)
    }

 
    # base 64 encode the private key and public key
    $base64pfx = [System.Convert]::ToBase64String($pfx_cert)
    $base64cer = [System.Convert]::ToBase64String($cer_cert)
 
    # getting id for the keyCredential object
    [string]$guid1 = New-Guid
    [string]$guid2 = New-Guid
 
    # get the custom key identifier from the certificate thumbprint:
    $hasher = [System.Security.Cryptography.HashAlgorithm]::Create('sha256')
    $hash = $hasher.ComputeHash([System.Text.Encoding]::UTF8.GetBytes($cert.Thumbprint))
    $customKeyIdentifier = [System.Convert]::ToBase64String($hash)
 
    # get end date and start date for our keycredentials
    $endDateTime = ($cert.NotAfter).ToUniversalTime().ToString( "yyyy-MM-ddTHH:mm:ssZ" )
    $startDateTime = ($cert.NotBefore).ToUniversalTime().ToString( "yyyy-MM-ddTHH:mm:ssZ" )
 
    # building our json payload
    $object = [ordered]@{    
    keyCredentials = @(       
         [ordered]@{            
            customKeyIdentifier = $customKeyIdentifier
            endDateTime = $endDateTime
            keyId = $guid1
            startDateTime = $startDateTime 
            type = "AsymmetricX509Cert"
            usage = "Sign"
            key = $base64pfx
            displayName = "CN=$fqdn" 
        },
        [ordered]@{            
            customKeyIdentifier = $customKeyIdentifier
            endDateTime = $endDateTime
            keyId = $guid2
            startDateTime = $startDateTime 
            type = "AsymmetricX509Cert"
            usage = "Verify"
            key = $base64cer
            displayName = "CN=$fqdn"   
        }
        )  
    passwordCredentials = @(
        [ordered]@{
            customKeyIdentifier = $customKeyIdentifier
            displayName = "CN=$fqdn"
            keyId = $guid1           
            endDateTime = $endDateTime
            startDateTime = $startDateTime
            secretText = $password
            hint = $null
        }
    )
    }
 
Connect-MgGraph -tenantId $tenantId -Scopes Application.ReadWrite.All
$graphuri = "https://graph.microsoft.com/v1.0/applications/$appObjId"
Invoke-MgGraphRequest -Method PATCH -Uri $graphuri -Body $object

    $json = $object | ConvertTo-Json -Depth 99
    Write-Host "JSON Payload:"
    Write-Output $json

Überprüfen des Tokensignaturschlüssels

Apps, die die Anspruchszuordnung aktiviert haben, müssen ihre Tokensignaturschlüssel validieren, indem sie appid={client_id} an ihre OpenID Connect-Metadatenanforderungen anhängen. Das folgende Beispiel zeigt das Format des OpenID Connect-Metadatendokuments, das Sie verwenden sollten:

https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration?appid={client-id}

Aktualisieren des Anwendungsmanifests

Alternativ können Sie für einzelne Mandantenanwendungen die acceptMappedClaims-Eigenschaft im true auf festlegen. Wie im apiApplication Ressourcentyp dokumentiert. Durch das Festlegen der Eigenschaft kann eine Anwendung die Anspruchszuordnung verwenden, ohne einen benutzerdefinierten Signaturschlüssel anzugeben.

Die angeforderte Tokenzielgruppe muss einen verifizierten Domänennamen Ihres Microsoft Entra-Mandanten verwenden. Das bedeutet, dass Sie Application ID URI (im Anwendungsmanifest durch identifierUris dargestellt) beispielsweise auf https://contoso.com/my-api oder https://contoso.onmicrosoft.com/my-api (unter Verwendung des Standardmandantennamens) festlegen müssen.

Wenn Sie keine überprüfte Domäne verwenden, gibt Microsoft Entra ID einen AADSTS501461-Fehlercode mit folgender Meldung aus: „_AcceptMappedClaims wird nur für eine Tokenzielgruppe, die mit der Anwendungs-GUID übereinstimmt, oder für eine Zielgruppe innerhalb der überprüften Domänen des Mandanten unterstützt. Ändern Sie entweder den Ressourcenbezeichner, oder verwenden Sie einen anwendungsspezifischen Signaturschlüssel.“

Erweiterte Anspruchsoptionen

Konfigurieren Sie erweiterte Anspruchsoptionen für OIDC-Anwendungen, um den gleichen Anspruch wie SAML-Token verfügbar zu machen. Ebenfalls für Anwendungen, die denselben Anspruch sowohl für SAML2.0- als auch für OIDC-Antwort-Tokens verwenden wollen.

Konfigurieren Sie erweiterte Anspruchsoptionen, indem Sie das Kontrollkästchen unter "Erweiterte Anspruchsoptionen " im Blatt "Ansprüche verwalten " aktivieren.

Zugehöriger Inhalt

• Ansprüche und Token, die in der Microsoft Entra-ID verwendet werden.