Verificatiestromen die worden ondersteund in MSAL

Microsoft Authentication Library (MSAL) ondersteunt verschillende autorisatietoekenken en gekoppelde tokenstromen voor gebruik door verschillende toepassingstypen en scenario's.

Tokens

Uw toepassing kan een of meer verificatiestromen gebruiken. Elke stroom gebruikt bepaalde tokentypen voor verificatie, autorisatie en het vernieuwen van tokens, en sommige gebruiken ook een autorisatiecode.

Interactieve en niet-interactieve verificatie

Verschillende van deze stromen ondersteunen interactieve en niet-interactieve tokenverwerving.

• Interactief: de autorisatieserver kan de gebruiker vragen gegevens in te voeren. Als u zich bijvoorbeeld wilt aanmelden, meervoudige verificatie (MFA) wilt uitvoeren of toestemming wilt verlenen voor meer machtigingen voor toegang tot resources.
• Niet-interactief : de gebruiker wordt mogelijk niet om invoer gevraagd. Ook wel stille tokenverwerving genoemd, probeert de toepassing een token op te halen met behulp van een methode waarbij de autorisatieserver de gebruiker mogelijk niet om invoer vraagt.

Uw MSAL-toepassing moet eerst proberen een token te verwerven op de achtergrond en pas terugvallen op de interactieve methode als de niet-interactieve poging mislukt. Raadpleeg Tokens verkrijgen en opslaan in cache met de Microsoft Authentication Library (MSAL) voor meer informatie over dit patroon.

Authorization code

De OAuth 2.0-autorisatiecodetoestemming kan worden gebruikt door web-apps, apps met één pagina (BEVEILIGD-WACHTWOORDVERIFICATIE) en systeemeigen toepassingen (mobiel en desktop) om toegang te krijgen tot beveiligde resources, zoals web-API's.

Wanneer gebruikers zich aanmelden bij webtoepassingen, ontvangt de toepassing een autorisatiecode. Die kan deze inwisselen voor een toegangstoken om web-API's aan te roepen.

In het voorgaande diagram is de toepassing:

1. Vraagt een autorisatiecode aan die is ingewisseld voor een toegangstoken.
2. Hiermee wordt het toegangstoken gebruikt om een web-API aan te roepen, zoals Microsoft Graph.

Beperkingen voor de autorisatiecode

• Voor toepassingen met één pagina is Proof Key for Code Exchange (PKCE) vereist bij het gebruik van de stroom voor het verlenen van autorisatiecode. PKCE wordt ondersteund door MSAL.

• Voor de OAuth 2.0-specificatie moet u een autorisatiecode gebruiken om slechts één keer een toegangstoken in te wisselen.

  Als u meerdere keren probeert een toegangstoken met dezelfde autorisatiecode te verkrijgen, wordt er een fout geretourneerd die vergelijkbaar is met het volgende door het Microsoft Identity Platform. Houd er rekening mee dat sommige bibliotheken en frameworks automatisch de autorisatiecode voor u aanvragen en dat het aanvragen van een code in dergelijke gevallen ook tot deze fout leidt.

  AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.

Client credentials

Met de OAuth 2-clientreferentiestroom kunt u toegang krijgen tot door het web gehoste resources met behulp van de identiteit van een toepassing. Dit type toekenning wordt vaak gebruikt voor S2S-interacties (server-naar-server) die op de achtergrond moeten worden uitgevoerd, zonder directe interactie van een gebruiker. Deze typen toepassingen worden vaak daemons of services genoemd.

Met de client credentials grant flow kan een webservice (een vertrouwelijke client) zijn eigen referenties gebruiken, in plaats van een gebruiker te imiteren, om zichzelf te authentiseren bij het aanroepen van een andere webservice. In dit scenario is de client doorgaans een webservice in de middelste laag, een daemon-service of een website. Voor een hoger zekerheidsniveau laat het Microsoft Identity-platform ook toe dat de aanroepende service een certificaat gebruikt als referentie (in plaats van een gedeeld geheim).

Application secrets

In het voorgaande diagram is de toepassing:

1. Hiermee verkrijgt u een token met behulp van een toepassingsgeheim of wachtwoordreferenties.
2. Gebruikt het token om resourceaanvragen te maken.

Certificates

In het voorgaande diagram is de toepassing:

1. Hiermee verkrijgt u een token met behulp van certificaatreferenties.
2. Gebruikt het token om resourceaanvragen te maken.

Dit type clientreferenties moet het volgende zijn:

• Geregistreerd bij Azure AD.
• Doorgegeven bij het maken van het vertrouwelijke clienttoepassingsobject in uw code.

Beperkingen voor clientreferenties

De vertrouwelijke clientstroom wordt niet ondersteund op mobiele platforms zoals Android, iOS of UWP (Universal Windows Platform). Mobiele toepassingen worden beschouwd als openbare clienttoepassingen die niet in staat zijn om de vertrouwelijkheid van verificatiegeheimen te garanderen.

Device code

Met de OAuth 2-apparaatcodestroom kunnen gebruikers zich aanmelden bij ingevoerde apparaten, zoals slimme tv's, IoT-apparaten (Internet of Things) en printers. Voor interactieve verificatie met Microsoft Entra ID is een webbrowser vereist. Wanneer het apparaat of besturingssysteem geen webbrowser biedt, biedt de apparaatcodestroom de mogelijkheid om een ander apparaat, zoals een computer of mobiele telefoon, te gebruiken om zich interactief aan te melden.

Door de stroom voor apparaatcodes te gebruiken, verkrijgt de toepassing tokens via een proces in twee stappen dat is ontworpen voor deze apparaten en besturingssystemen.

In het voorgaande diagram:

1. Wanneer de gebruiker moet worden geverifieerd, biedt de app een code. De gebruiker wordt dan gevraagd een ander apparaat te gebruiken, zoals een smartphone met internetverbinding, om een URL te bezoeken (bijvoorbeeld https://microsoft.com/devicelogin). De gebruiker wordt vervolgens gevraagd de code in te voeren en doorloopt een normale verificatie-ervaring, waaronder toestemmingsprompts en meervoudige verificatie, indien nodig.
2. Na een geslaagde verificatie ontvangt de aanvragende toepassing de vereiste tokens van het Microsoft Identity Platform en gebruikt deze om de web-API-aanroepen uit te voeren die nodig zijn.

Beperkingen voor de apparaatcode

• De apparaatcodeflow is alleen beschikbaar voor openbare clienttoepassingen.
• Wanneer u een openbare clienttoepassing in MSAL initialiseert, gebruikt u een van deze instantie-indelingen:
  • Op tenant gebaseerd: https://login.microsoftonline.com/{tenant}/, waarbij {tenant} de GUID de tenant-id of een domeinnaam vertegenwoordigt die is gekoppeld aan de tenant.
  • Werk- en schoolaccounts: https://login.microsoftonline.com/organizations/.

Implicit grant

De impliciete toekenning is vervangen door de autorisatiecodestroom door PKCE als voorkeursstroom en veiligere tokentoekenstroom voor toepassingen aan de clientzijde met één pagina (SPA's). Als je een SPA bouwt, gebruik dan de autorisatiecode-flow met PKCE.

Web-apps met één pagina die zijn geschreven in JavaScript (inclusief frameworks zoals Angular, Vue.js of React.js), worden gedownload van de server en de bijhorende code wordt rechtstreeks in de browser uitgevoerd. Omdat hun code aan clientzijde wordt uitgevoerd in de browser en niet op een webserver, hebben deze verschillende beveiligingskenmerken dan traditionele webtoepassingen op de server. Vóór de beschikbaarheid van Proof Key for Code Exchange (PKCE) voor de stroom voor autorisatiecodes werd de stroom voor impliciete toekenning gebruikt door SPA's om de reactiesnelheid en efficiëntie te verbeteren bij het verkrijgen van toegangstokens.

Met de impliciete OAuth 2-toekenningsstroom kan de app toegangstokens ophalen van het Microsoft-identiteitsplatform zonder een exchange van referenties voor de back-endserver uit te voeren. Met de stroom voor impliciete toekenning kan een app zich aanmelden bij de gebruiker, een sessie onderhouden en tokens ophalen voor andere web-API's vanuit de JavaScript-code die is gedownload en uitgevoerd door de gebruikersagent (meestal een webbrowser).

Beperkingen voor impliciete toekenning

De stroom voor impliciete toekenning omvat geen toepassingsscenario's die platformoverschrijdende JavaScript-frameworks gebruiken, zoals Electron of React Native. Platformoverschrijdende frameworks zoals deze vereisen extra mogelijkheden voor interactie met de systeemeigen desktop- en mobiele platformen waarop ze worden uitgevoerd.

Tokens die zijn uitgegeven via de impliciete stroommodus hebben een lengtebeperking omdat ze worden geretourneerd naar de browser in de URL (waar response_mode dat wel isquery).fragment Sommige browsers beperken de lengte van de URL in de browserbalk en kunnen falen als deze te lang is. Deze impliciete stroomtokens bevatten dan ook géén claims voor groups of wids.

On-behalf-of (OBO)

De stroom OAuth 2 namens de verificatiestroom wordt gebruikt wanneer een toepassing een service of web-API aanroept die op zijn beurt een andere service of web-API moet aanroepen met behulp van een gedelegeerde gebruikersidentiteit en -machtigingen die moeten worden doorgegeven via de aanvraagketen. Voor de service in de middelste laag om geverifieerde aanvragen te kunnen indienen bij de downstreamservice, moet er namens de aanvragende gebruiker een toegangstoken van het Microsoft-identiteitsplatform worden beveiligd.

In het voorgaande diagram:

1. verkrijgt de toepassing een toegangstoken voor de web-API.
2. Een client (een web-, desktop- of mobiele toepassing of een toepassing met één pagina) roept een beveiligde web-API aan, waarbij het toegangstoken wordt toegevoegd als bearer-token in de verificatieheader van de HTTP-aanvraag. De web-API verifieert de gebruiker.
3. Wanneer de client de web-API aanroept, vraagt de web-API een ander token aan namens de gebruiker.
4. De beveiligde web-API gebruikt dit token om een downstream-web-API aan te roepen namens de gebruiker. De web-API kan later ook tokens aanvragen voor andere downstream-API's (maar nog steeds namens dezelfde gebruiker).

Username/password (ROPC)

Met de OAuth 2-referenties voor het wachtwoord van de resource-eigenaar (ROPC) kan een toepassing zich aanmelden bij de gebruiker door het wachtwoord rechtstreeks te verwerken. U kunt de gebruikersnaam/wachtwoordmethode gebruiken in uw desktoptoepassing om ongemerkt een token te verkrijgen. Er is geen gebruikersinterface vereist tijdens het gebruik van de toepassing.

Sommige toepassingsscenario's, zoals DevOps, kunnen ROPC nuttig vinden, maar u moet dit vermijden in elke toepassing waarin u een interactieve gebruikersinterface voor gebruikersaanmelding biedt.

In het voorgaande diagram is de toepassing:

1. Hiermee verkrijgt u een token door de gebruikersnaam en het wachtwoord naar de id-provider te verzenden.
2. Roept een web-API aan met behulp van het token.

Als u een token op de achtergrond wilt verkrijgen op computers die lid zijn van een Windows-domein, raden we u aan om wam (Web Account Manager) te gebruiken in plaats van ROPC. Voor andere scenario's gebruikt u de apparaatcode stroom.

Beperkingen voor ROPC

De volgende beperkingen zijn van toepassing op de toepassingen die de ROPC-stroom gebruiken:

• Eenmalige aanmelding wordt niet ondersteund.
• Meervoudige verificatie (MFA) wordt niet ondersteund.
  • Neem contact op met uw tenantbeheerder voordat u deze stroom gebruikt. MFA is een veelgebruikte functie.
• Voorwaardelijke toegang wordt niet ondersteund.
• ROPC werkt alleen voor werk- en schoolaccounts.
• Persoonlijke Microsoft-accounts (MSA) worden niet ondersteund door ROPC.
• ROPC wordt ondersteund in .NET Desktop- en .NET-toepassingen.
• ROPC wordt niet ondersteund in Universeel Windows-platform (UWP)-toepassingen.
• ROPC in Microsoft Entra External ID wordt alleen ondersteund voor lokale accounts.
  • Zie ropc-referenties (ROPC) met B2C voor informatie over ROPC in MSAL.NET en externe Microsoft Entra-id.

Geïntegreerde Windows-verificatie (IWA)

MSAL ondersteunt geïntegreerde Windows-verificatie (IWA) voor desktop- en mobiele toepassingen die worden uitgevoerd op windows-computers die lid zijn van een domein of op Windows-computers die lid zijn van Microsoft Entra ID. Door IWA te gebruiken, verkrijgen deze toepassingen een token op de achtergrond zonder tussenkomst van de gebruikersinterface.

In het voorgaande diagram is de toepassing:

1. Hiermee verkrijgt u een token met geïntegreerde Windows-verificatie.
2. Gebruikt het token om resourceaanvragen te maken.

Beperkingen voor IWA

• Compatibility. Geïntegreerde Windows-verificatie (IWA) is ingeschakeld voor .NET-desktop-, .NET- en UWP-apps (Universal Windows Platform). IWA biedt alleen ondersteuning voor ADFS-federatieve gebruikers: gebruikers die zijn gemaakt in Active Directory en worden ondersteund door Microsoft Entra-id. Gebruikers die rechtstreeks in Microsoft Entra ID zijn gemaakt zonder Active Directory-backing (beheerde gebruikers) kunnen deze verificatiestroom niet gebruiken.
• Meervoudige verificatie (MFA). IWA-niet-interactieve (stille) verificatie kan mislukken als MFA is ingeschakeld in de Microsoft Entra ID-tenant en er een MFA-uitdaging wordt uitgegeven door Microsoft Entra ID. Als IWA mislukt, moet u terugvallen op een interactieve verificatiemethode zoals eerder is beschreven. Microsoft Entra ID maakt gebruik van AI om te bepalen wanneer tweeledige verificatie is vereist. Tweeledige verificatie is doorgaans vereist wanneer een gebruiker zich aanmeldt vanuit een ander land of een andere regio, wanneer deze is verbonden met een bedrijfsnetwerk zonder een VPN te gebruiken, en soms wanneer deze zijn verbonden via een VPN. Omdat de configuratie en uitdagingsfrequentie van MFA mogelijk buiten uw controle valt als de ontwikkelaar, moet uw toepassing een fout bij het verkrijgen van tokens op de achtergrond van IWA afhandelen.
• Beperkingen voor autoriteits-URI's. De instantie die is doorgegeven bij het maken van de openbare clienttoepassing, moet een van de volgende zijn:
  • https://login.microsoftonline.com/{tenant}/ - Deze instantie geeft een toepassing met één tenant aan waarvan de aanmeldingsdoelgroep is beperkt tot de gebruikers in de opgegeven Microsoft Entra ID-tenant. De waarde {tenant} kan de tenant-id zijn in het GUID-formulier of de domeinnaam die is gekoppeld aan de tenant.
  • https://login.microsoftonline.com/organizations/ - Deze instantie geeft een toepassing met meerdere tenants aan waarvan de aanmeldingsdoelgroep gebruikers is in een Microsoft Entra ID-tenant.
• Personal accounts. Autoriteitswaarden mogen niet bevatten /common of /consumers omdat persoonlijke Microsoft-accounts (MSA) niet worden ondersteund door IWA.
• Consent requirements. Omdat IWA een stille stroom is, moet de gebruiker van uw toepassing eerder toestemming hebben gegeven om de toepassing te gebruiken of moet de tenantbeheerder eerder toestemming hebben gegeven voor alle gebruikers in de tenant om de toepassing te gebruiken. Om aan beide vereisten te voldoen, moet een van deze bewerkingen zijn voltooid:
  • U als ontwikkelaar van de toepassing hebt voor uzelf Grant geselecteerd in De Azure-portal.
  • Een tenantbeheerder heeft Beheerderstoestemming verlenen/intrekken geselecteerd voor {tenantdomein} op het tabblad API-machtigingen van de app-registratie in Azure Portal. Raadpleeg Machtigingen toevoegen voor toegang tot uw web-API.
  • U hebt gebruikers een manier geboden om toestemming te geven voor de toepassing; zie Overzicht van machtigingen en toestemming in het Microsoft Identity Platform.
  • U hebt een manier opgegeven voor de tenantbeheerder om toestemming te geven voor de toepassing; zie Overzicht van machtigingen en toestemming in het Microsoft Identity Platform.

Next steps

Nu u de verificatiestromen hebt bekeken die worden ondersteund door MSAL, leert u hoe u de tokens die in deze stromen worden gebruikt, in de cache opneemt en in de cache opneemt.