Microsoft Entra MFA gebruiken met een externe provider (preview)

In dit artikel wordt beschreven hoe een externe verificatieprovider verbinding maakt met Meervoudige Verificatie (MFA) van Microsoft Entra.

Wanneer een gebruiker zich aanmeldt, worden de tenantbeleidsregels geëvalueerd. De verificatievereisten worden bepaald op basis van de resource waartoe de gebruiker toegang probeert te krijgen.

Er kunnen meerdere beleidsregels van toepassing zijn op de aanmelding, afhankelijk van hun parameters. Deze parameters omvatten gebruikers en groepen, toepassingen, het platform, het niveau van aanmeldingsrisico's en meer.

Op basis van de verificatievereisten moet de gebruiker zich mogelijk aanmelden met een andere factor om te voldoen aan de MFA-vereiste. Het type tweede factor moet een aanvulling vormen op het type eerste factor.

De tenantbeheerder voegt externe verificatiemethoden toe aan De Microsoft Entra-id. Als voor een tenant een externe verificatiemethode voor MFA is vereist, wordt de aanmelding beschouwd als voldoen aan de MFA-vereiste nadat Microsoft Entra ID beide valideert:

• De eerste factor is voltooid met Microsoft Entra ID.
• De tweede factor werd voltooid met de externe verificatiemethode.

Deze validatie voldoet aan de MFA-vereiste voor twee of meer typen methoden:

• Iets wat u weet (kennis)
• Iets wat je hebt (bezit)
• Inherente eigenschappen, iets wat je bent

Externe verificatiemethoden worden geïmplementeerd boven op OpenID Connect (OIDC). Voor deze implementatie zijn ten minste drie openbaar gerichte eindpunten vereist voor het implementeren van een externe verificatiemethode:

• Een OIDC Discovery-eindpunt, zoals beschreven in detectie van metagegevens van providers
• Een geldig OIDC-verificatie-eindpunt
• Een URL waarin de openbare certificaten van de provider worden gepubliceerd

Zo werkt aanmelden met een externe verificatiemethode:

1. Een gebruiker probeert zich aan te melden met een eerste factor, zoals een wachtwoord, voor een toepassing die wordt beveiligd door Microsoft Entra-id.

2. Microsoft Entra ID bepaalt dat aan een andere factor moet worden voldaan (bijvoorbeeld als een beleid voor voorwaardelijke toegang MFA vereist).

3. De gebruiker kiest de externe verificatiemethode als een tweede factor.

4. Microsoft Entra ID leidt de browsersessie van de gebruiker om naar de URL van de externe verificatiemethode.

   Deze URL wordt gedetecteerd vanuit de detectie-URL die een beheerder heeft ingericht bij het maken van de externe verificatiemethode.

   De toepassing biedt een verlopen of bijna verlopen token dat informatie bevat om de gebruiker en tenant te identificeren.

5. De externe verificatieprovider valideert dat het token afkomstig is van Microsoft Entra-id en controleert de inhoud van het token.

6. De externe verificatieprovider kan Microsoft Graph aanroepen om aanvullende informatie over de gebruiker op te halen.

7. De externe verificatieprovider voert alle acties uit die nodig zijn, zoals het verifiëren van de gebruiker met een referentie.

8. De externe verificatieprovider leidt de gebruiker terug naar Microsoft Entra-id met een geldig token, inclusief alle vereiste claims.

9. Microsoft Entra ID valideert dat de handtekening van het token afkomstig is van de geconfigureerde externe verificatieprovider en controleert vervolgens de inhoud van het token.

10. Microsoft Entra ID valideert het token op basis van de vereisten.

11. Als de validatie slaagt, betekent dit dat de gebruiker aan de MFA-vereiste voldoet. De gebruiker moet mogelijk ook voldoen aan andere beleidsvereisten.

Een nieuwe externe verificatieprovider configureren met Microsoft Entra-id

Om id_token_hint te verstrekken, hebben externe verificatiemethoden een toepassing nodig die de integratie vertegenwoordigt. U kunt de toepassing op twee manieren maken:

• In elke tenant die gebruikmaakt van de externe provider.
• Als één multitenant-toepassing. Als u de integratie voor hun tenant wilt inschakelen, moeten beheerders van bevoorrechte rollen toestemming verlenen.

Het gebruik van een multitenant-toepassing kan de kans op onjuiste configuratie in elke tenant verminderen. Providers kunnen ook wijzigingen aanbrengen in metagegevens (bijvoorbeeld antwoord-URL's op één plaats), in plaats van dat elke tenant de wijzigingen moet aanbrengen.

Als u een multitenant-toepassing wilt configureren, moet de providerbeheerder eerst:

1. Maak een Microsoft Entra ID-tenant (als ze er nog geen hebben).

2. Registreer een toepassing in hun tenantaccount.

3. Selecteer in de toepassing onder Ondersteunde accounttypen de optie Accounts in een willekeurige organisatiedirectory (Elke Microsoft Entra ID-tenant - Multitenant).

4. Voeg de gedelegeerde machtiging openid en profile waarden voor Microsoft Graph toe.

5. Publiceer geen scopes in deze toepassing.

6. Voeg de geldige authorization_endpoint URL's van de externe id-provider toe aan die toepassing als antwoord-URL's.

   Notitie

   Voeg in de registratie van de toepassing de authorization_endpoint waarde toe die is opgegeven in het detectiedocument van de provider als omleidings-URL. Anders krijgt u de volgende fout: "ENTRA IDSTS50161: Kan autorisatie-URL van externe claimprovider niet valideren!"

Het registratieproces van de toepassing maakt een toepassing met verschillende eigenschappen. U hebt deze eigenschappen nodig voor ons scenario.

Een ander geldig model voor de ondersteuning van integratie is het gebruik van een toepassing voor elke tenant. Als u een registratie met één tenant gebruikt, moet de tenantbeheerder een toepassingsregistratie maken met de eigenschappen in de voorgaande tabel voor een toepassing met één tenant.

Optionele claims configureren

Een provider kan meer claims configureren met behulp van optionele claims voor id_token.

Een externe verificatiemethode toevoegen aan Microsoft Entra-id

Externe id-providergegevens worden opgeslagen in het beleid voor verificatiemethoden van elke tenant. De providergegevens worden opgeslagen als verificatiemethode van het type externalAuthenticationMethodConfiguration.

Elke provider heeft één vermelding in het lijstobject van het beleid. Elke vermelding moet het volgende vermelden:

• Als de methode is ingeschakeld.
• De opgenomen groepen die de methode kunnen gebruiken.
• De uitgesloten groepen die de methode niet kunnen gebruiken.

Als u de MFA-vereiste voor gebruikersaanmelding wilt instellen, kunnen gebruikers met de rol Beheerder voor voorwaardelijke toegang een beleid maken dat de MFA-verlening vereist. Externe verificatiemethoden worden momenteel niet ondersteund met verificatiesterkten.

Meer informatie over het toevoegen van een externe verificatiemethode in het Microsoft Entra-beheercentrum.

Interactie van Microsoft Entra ID met provider

In de volgende secties worden providervereisten uitgelegd en worden voorbeelden weergegeven voor hoe Microsoft Entra ID communiceert met een provider.

Detectie van metagegevens van providers

Een externe id-provider moet een OIDC Discovery-eindpunt opgeven. Dit eindpunt wordt gebruikt om meer configuratiegegevens op te halen.

De detectie-URL moet het https schema gebruiken en moet eindigen op /.well-known/openid-configuration. U kunt geen extra padsegmenten, queryreeksen of fragmenten na dit segment opnemen. De volledige detectie-URL moet worden opgenomen in de detectie-URL die u configureert wanneer u de externe verificatiemethode maakt.

Het eindpunt retourneert een JSON-document met metagegevens van een provider dat daar wordt gehost. Het eindpunt moet ook een inhoudslengte-header retourneren die geldig is. Het metagegevensdocument moet voldoen aan OpenID Connect Discovery 1.0 (waarin errataset 2 is opgenomen) en alle vereiste OIDC-metagegevensvelden bevatten.

De metagegevens van de provider moeten de gegevens bevatten die worden vermeld in de volgende tabel. Deze waarden zijn vereist voor dit uitbreidbaarheidsscenario. Het JSON-metagegevensdocument bevat mogelijk meer informatie.

Zie Metagegevens van provider voor het OIDC-document met de waarden voor metagegevens van de provider.

https://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
  "authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
  "claims_supported": [
    "email"
  ],
  "grant_types_supported": [
    "implicit"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "issuer": "https://customcaserver.azurewebsites.net/v2.0",
  "jwks_uri": "https://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

https://customcaserver.azurewebsites.net/.well-known/jwks
{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
      "e": "AQAB",
      "x5c": [
        "cZa3jz...Wo0rzA="
      ]
    }
  ]
}

Voorbeelden van Discovery-URL's en uitgevende instanties

In de volgende voorbeelden ziet u geldige en ongeldige combinaties van detectie-URL's en verleners voor deze integratie.

Geldige detectie-URL en uitgeverparen

• Ontdekkings-URL: https://example.com/.well-known/openid-configuration
  Uitgevende instelling: https://example.com
• Ontdekkings-URL: https://example.com:8443/.well-known/openid-configuration
  Uitgevende instelling: https://example.com:8443
• Ontdekkings-URL: https://example.com/tenant1/.well-known/openid-configuration
  Uitgevende instelling: https://example.com/tenant1

Ongeldige ontdekking-URL en uitgever-voorbeelden

• Ontdekkings-URL: https://example.com/.well-known/openid-configuration
  Verlener: https://example.com:443/ (Standaard-HTTPS-poort expliciet toegevoegd aan verlener.)
• Ontdekkings-URL: https://example.com:443/.well-known/openid-configuration
  Verlener: https://example.com/ (Poort komt niet overeen.)
• Ontdekkings-URL: https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
  Verlener: https://example.com (U kunt geen queryreeks opnemen in een detectie-URL.)

Cacheopslag van providermetagegevens

Om de prestaties te verbeteren, slaat Microsoft Entra ID metagegevens op die de provider retourneert, inclusief de sleutels. Het opslaan van metagegevens van providers voorkomt een detectieaanroep telkens wanneer Microsoft Entra ID communiceert met een externe id-provider.

Deze cache wordt elke 24 uur vernieuwd. We raden providers aan deze stappen uit te voeren om hun sleutels over te rollen:

1. Publiceer het bestaande certificaat en het nieuwe certificaat in jwks_uri.
2. Blijf aanmelden met bestaand certificaat totdat de Microsoft Entra ID-cache wordt vernieuwd, verlopen of bijgewerkt (elke 2 dagen).
3. Schakel over naar aanmelden met New Cert.

We publiceren geen planningen voor belangrijke rollovers. De afhankelijke service moet voorbereid zijn om zowel onmiddellijke als periodieke overgangen te verwerken. We raden u aan een speciale bibliotheek te gebruiken die voor dit doel is gebouwd, zoals azure-activedirectory-identitymodel-extensions-for-dotnet. Voor meer informatie, zie Rollover voor ondertekeningssleutels in Microsoft Entra ID.

Detectie van metagegevens van Microsoft Entra-id

Providers moeten ook de openbare sleutels van Microsoft Entra-id ophalen om de tokens te valideren die zijn uitgegeven door Microsoft Entra-id.

Detectie-eindpunten voor metagegevens van Microsoft Entra ID:

• Wereldwijd Azure: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• Azure voor de Amerikaanse overheid: https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
• Microsoft Azure beheerd door 21Vianet: https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

U kunt de openbare-sleutel-id van het token (de 'kid' van JSON Web Signature (JWS)) gebruiken om te bepalen welke sleutels uit de jwks_uri eigenschap moeten worden opgehaald om de Microsoft Entra ID-tokenhandtekening te valideren.

Tokens valideren die zijn uitgegeven door Microsoft Entra-id

Zie Een id-token valideren voor informatie over het valideren van de tokens die zijn uitgegeven door Microsoft Entra-id. Er zijn geen speciale stappen voor de gebruikers van onze detectiemetagegevens.

U vindt alle details over tokenvalidatie in de tokenvalidatiebibliotheek van Microsoft. U kunt deze details ook controleren door de broncode te doorzoeken. Zie Azure-voorbeelden voor een voorbeeld.

Nadat de validatie is voltooid, kunt u met de claims payload werken om details over de gebruiker en de bijbehorende tenant op te halen.

Microsoft Entra ID-aanroep naar de externe id-provider

Microsoft Entra ID maakt gebruik van de impliciete OIDC-stroom om te communiceren met de externe id-provider. Wanneer u deze stroom gebruikt, vindt communicatie met de provider plaats met behulp van alleen het autorisatie-eindpunt van de provider.

Als u de provider wilt informeren over de gebruiker voor wie Microsoft Entra ID de aanvraag doet, geeft Microsoft Entra-id een token door via de id_token_hint parameter.

Deze aanroep wordt gedaan via een POST aanvraag omdat een grote lijst met parameters wordt doorgegeven aan de provider. Een grote lijst voorkomt het gebruik van browsers die de lengte van een GET aanvraag beperken.

De parameters voor verificatieaanvragen worden vermeld in de volgende tabel.

Voorbeeld van een omleidings-URI

De omleidings-URI's moeten worden geregistreerd bij de externe provider. De omleidings-URI's die u kunt verzenden, zijn:

• Wereldwijd Azure: https://login.microsoftonline.com/common/federation/externalauthprovider
• Azure voor de Amerikaanse overheid: https://login.microsoftonline.us/common/federation/externalauthprovider
• Microsoft Azure beheerd door 21Vianet: https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

Voorbeeld van een externe verificatiemethode die voldoet aan MFA

Hier volgt een voorbeeld waarin een externe verificatiemethode voldoet aan de MFA-vereisten. In dit voorbeeld kan een provider weten welke claims Microsoft Entra ID verwacht.

Microsoft Entra ID maakt gebruik van de combinatie van de acr en amr waarden om te valideren dat:

• De verificatiemethode die voor de tweede factor wordt gebruikt, voldoet aan de MFA-vereiste.
• De verificatiemethode is een ander type dan de methode die wordt gebruikt om de eerste factor voor aanmelding bij Microsoft Entra-id te voltooien.

{
  "id_token": {
    "acr": {
      "essential": true,
      "values":["possessionorinherence"]
    },
    "amr": {
      "essential": true,
      "values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
    }
  }
}

Standaardclaims voor id_token_hint

In deze sectie wordt de vereiste inhoud beschreven van het token dat wordt doorgegeven als id_token_hint in de aanvraag die is ingediend bij de provider. Het token kan meer claims bevatten dan in de volgende tabel wordt weergegeven.

Om te voorkomen dat het token wordt gebruikt voor iets anders dan een hint, wordt het uitgegeven in de verlopen status. Het token is ondertekend en kan worden geverifieerd met behulp van de gepubliceerde metagegevens van Microsoft Entra ID-detectie.

Optionele claims van Microsoft Entra-id

Als een provider optionele claims van Microsoft Entra ID nodig heeft, kunt u de volgende optionele claims configureren voorid_token: given_name, family_name, preferred_username, . upn Zie Optionele claims voor meer informatie.

Aanbevolen gebruik van claims

U wordt aangeraden accounts aan de providerzijde te koppelen aan het account in Azure met behulp van de oid en tid claims. Deze twee claims zijn gegarandeerd uniek voor het account in de huurdersomgeving.

Voorbeeld van id_token_hint

Hier is een voorbeeld van id_token_hint voor een directorylid:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "Test User 2",
  "preferred_username": "testuser2@contoso.com"
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Hier is een voorbeeld van id_token_hint voor een gastgebruiker in de tenant.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "External Test User (Hotmail)",
  "preferred_username": "externaltestuser@hotmail.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Voorgestelde acties voor externe id-providers

We raden aan dat externe id-providers de volgende items voltooien. De lijst is niet volledig en providers moeten andere validatiestappen voltooien naar wens.

• Vanuit de aanvraag:

  • Zorg ervoor dat de redirect_uri is gepubliceerd zoals beschreven in Microsoft Entra ID-aanroep naar de externe identiteitsprovider.
  • Zorg ervoor dat de geconfigureerde detectie-URL HTTPS gebruikt en eindigt met /.well-known/openid-configuration. Zorg er ook voor dat deze geen queryparameters of fragment-id's bevat. Zorg ervoor dat de waarde van de uitgever exact overeenkomt met het detectiedocument.
  • Zorg ervoor dat de client_id waarde is toegewezen aan Microsoft Entra-id, zoals ABCD.
  • De provider moet eerst de id_token_hint die Microsoft Entra ID eraan presenteert, valideren.

• Uit de claims in het id_token_hint

  • (Optioneel) Maak een aanroep naar Microsoft Graph om andere details over deze gebruiker op te halen. De oid en tid claims in id_token_hint zijn in dit verband nuttig. Zie voor de details over de claims die zijn opgegeven in id_token_hint, Standaardclaims id_token_hint.

• Voer eventuele andere verificatieactiviteiten uit voor het product van de provider.

• Afhankelijk van het resultaat van de acties van de gebruiker en andere factoren, zou de provider vervolgens een antwoord maken en terugsturen naar Microsoft Entra-id, zoals wordt uitgelegd in de volgende sectie.

Microsoft Entra ID-verwerking van het antwoord van de provider

De provider moet POST gebruiken om een antwoord terug te sturen naar de redirect_uri. De volgende parameters moeten worden opgegeven voor een geslaagd antwoord:

Bij succes zou de provider vervolgens een id_token waarde voor de gebruiker uitgeven. Microsoft Entra ID maakt gebruik van de gepubliceerde OIDC-metagegevens om te controleren of het token de verwachte claims bevat en voert een andere tokenvalidatie uit die OIDC vereist is.

Ondersteunde ACR-claims

Ondersteunde amrclaims

Microsoft Entra ID vereist dat MFA tevreden is over het uitgeven van een token met MFA-claims. Als gevolg hiervan kunnen alleen methoden met een ander type voldoen aan de tweede factorvereiste. Zoals eerder vermeld, zijn de verschillende methodetypen die kunnen worden gebruikt om aan de tweede factor te voldoen kennis, bezit en inherentie.

Microsoft Entra ID valideert de soorttoewijzing op basis van de volgende tabel.

Microsoft Entra ID beschouwt MFA als bevredigend als er geen problemen zijn gevonden met het token, en geeft de gebruiker een token uit. Anders mislukt de aanvraag van de gebruiker.

Fout wordt aangegeven door parameters voor foutreacties uit te geven.

Microsoft Entra ID beschouwt de aanvraag als geslaagd als id_token parameter aanwezig is in het antwoord en het token geldig is. Anders wordt de aanvraag als mislukt beschouwd. Microsoft Entra ID mislukt de oorspronkelijke verificatiepoging vanwege de vereiste van het beleid voor voorwaardelijke toegang.

Microsoft Entra ID verwijdert aan zijn kant de status van de verificatiepoging ongeveer 5 minuten na de omleiding naar de provider.

Afhandeling van foutreacties in Microsoft Entra ID

Microsoft Azure-services gebruiken een correlationId waarde om aanroepen te correleren tussen verschillende interne en externe systemen. Het fungeert als een algemene id van de hele bewerking of stroom die mogelijk meerdere HTTP-aanroepen omvat. Wanneer er een fout optreedt tijdens een van de bewerkingen, bevat het antwoord een veld met de naam Correlatie-id.

Wanneer u contact op neemt met Microsoft-ondersteuning of een vergelijkbare service, geeft u de correlatie-id-waarde op. Hiermee kunt u sneller toegang krijgen tot de telemetrie en logboeken.

Voorbeeld:

ENTRA IDSTS70002: Error validating credentials. ENTRA IDSTS50012: External ID token from issuer 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' failed signature verification. KeyID of token is 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u'

Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333

Correlation ID: aaaa0000-bb11-2222-33cc-444444dddddd

Timestamp: 2023-07-24 16:51:34Z

Aangepaste bedieningselementen en externe verificatiemethoden

In Microsoft Entra ID kunnen externe verificatiemethoden en aangepaste besturingselementen voor voorwaardelijke toegang parallel worden uitgevoerd terwijl klanten zich voorbereiden op en migreren naar externe verificatiemethoden.

Klanten die momenteel gebruikmaken van een integratie met een externe provider met behulp van aangepaste besturingselementen, kunnen deze blijven gebruiken en elk beleid voor voorwaardelijke toegang dat ze hebben geconfigureerd voor het beheren van de toegang. Beheerders wordt aangeraden tijdens de migratieperiode een parallelle set beleidsregels voor voorwaardelijke toegang te maken:

• Voor beleid moet de toegangscontrole Meervoudige verificatie vereisen worden gebruikt in plaats van de aangepaste toegangscontrole.

  Notitie

  Bepaal controles op basis van verificatiesterkten, inclusief de ingebouwde MFA-sterkte, die niet zijn vervuld door de externe verificatiemethode. Beleidsregels moeten alleen worden geconfigureerd met Meervoudige authenticatie vereisen.

• Het nieuwe beleid kan eerst worden getest met een subset van gebruikers. De testgroep wordt uitgesloten van het beleid waarvoor aangepaste besturingselementen zijn vereist en die zijn opgenomen in het beleid waarvoor MFA is vereist. Wanneer de beheerder ervan overtuigd is dat het beleid dat MFA vereist wordt nageleefd door de externe authenticatiemethode, kan de beheerder alle vereiste gebruikers opnemen in het beleid met de MFA-toekenning. Het beleid dat is geconfigureerd voor aangepaste besturingselementen, kan worden verplaatst naar de instelling Uit .

Integratieondersteuning

Als u problemen ondervindt bij het bouwen van integratie van externe verificatiemethoden met Microsoft Entra-id, kan de onafhankelijke oplossingsleverancier (CxE) van Microsoft Customer Experience Engineering (ISV) mogelijk helpen. Als u contact wilt opnemen met het CxE ISV-team, dient u een aanvraag in voor hulp.

Verwijzingen

• OAuth2.0- en OIDC-specificatie

Woordenlijst

Verwante inhoud

• Zie Een externe verificatiemethode beheren in Microsoft (preview) voor meer informatie over het configureren van een externe verificatiemethode in het Microsoft Entra-beheercentrum.