Toepassingstypen die kunnen worden gebruikt in Active Directory B2C

Belangrijk

Vanaf 1 mei 2025 is Azure AD B2C niet meer beschikbaar voor nieuwe klanten. Meer informatie vindt u in onze veelgestelde vragen.

Azure Active Directory B2C (Azure AD B2C) ondersteunt verificatie voor verschillende moderne toepassingsarchitecturen. Ze zijn allemaal gebaseerd op de industriestandaardprotocollen OAuth 2.0 of OpenID Connect. In dit artikel worden de typen toepassingen beschreven die u kunt bouwen, onafhankelijk van de taal of het platform dat u wilt gebruiken. Het helpt u ook de scenario's op hoog niveau te begrijpen voordat u begint met het bouwen van toepassingen.

Elke toepassing die gebruikmaakt van Azure AD B2C, moet worden geregistreerd in uw Azure AD B2C-tenant met behulp van Azure Portal. Het registratieproces van de toepassing verzamelt en wijst waarden toe, zoals:

• Een toepassings-id die uw toepassing uniek identificeert.
• Een antwoord-URL die kan worden gebruikt om antwoorden terug te sturen naar uw toepassing.

Elke aanvraag die naar Azure AD B2C wordt verzonden, specificeert een gebruikersstroom (ingebouwd beleid) of een aangepast beleid waarmee het gedrag van Azure AD B2C wordt bepaald. Met beide beleidstypen kunt u een zeer aanpasbare set gebruikerservaringen maken.

De interactie van elke toepassing volgt een vergelijkbaar patroon op hoog niveau:

1. De toepassing stuurt de gebruiker naar het v2.0-eindpunt om een beleid uit te voeren.
2. De gebruiker voltooit het beleid volgens de beleidsdefinitie.
3. De toepassing ontvangt een beveiligingstoken van het v2.0-eindpunt.
4. De toepassing gebruikt het beveiligingstoken voor toegang tot beveiligde gegevens of een beveiligde resource.
5. De resourceserver valideert het beveiligingstoken om te controleren of toegang kan worden verleend.
6. De toepassing vernieuwt regelmatig het beveiligingstoken.

Deze stappen kunnen enigszins verschillen op basis van het type toepassing dat u bouwt.

Webtoepassingen

Voor webtoepassingen (waaronder .NET, PHP, Java, Ruby, Python en Node.js) die worden gehost op een webserver en toegankelijk zijn via een browser, ondersteunt Azure AD B2C OpenID Connect voor alle gebruikerservaringen. In de Azure AD B2C-implementatie van OpenID Connect initieert uw webtoepassing gebruikerservaringen door verificatieaanvragen uit te geven aan Microsoft Entra ID. Het resultaat van de aanvraag is een id_token. Dit beveiligingstoken vertegenwoordigt de identiteit van de gebruiker. Het biedt ook informatie over de gebruiker in de vorm van claims:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Meer informatie over de typen tokens en claims die beschikbaar zijn voor een toepassing in de azure AD B2C-tokenreferentie.

In een webtoepassing voert elke uitvoering van een beleid de volgende stappen op hoog niveau uit:

1. De gebruiker bladert naar de webtoepassing.
2. De webtoepassing leidt de gebruiker om naar Azure AD B2C dat het beleid aangeeft dat moet worden uitgevoerd.
3. De gebruiker voert het beleid uit.
4. Azure AD B2C retourneert een id_token naar de browser.
5. De id_token wordt geplaatst op de omleidings-URI.
6. Het id_token is gevalideerd en er wordt een sessiecooky ingesteld.
7. Er wordt een beveiligde pagina geretourneerd aan de gebruiker.

Validatie van de id_token sleutel voor openbare ondertekening die is ontvangen van Microsoft Entra ID is voldoende om de identiteit van de gebruiker te verifiëren. Met dit proces wordt ook een sessiecooky ingesteld die kan worden gebruikt om de gebruiker op volgende paginaaanvragen te identificeren.

Als u dit scenario in actie wilt zien, kunt u een van de aanmeldingscodevoorbeelden voor webtoepassingen proberen in de sectie Aan de slag.

Naast het vergemakkelijken van eenvoudige aanmelding, moet een webtoepassing mogelijk ook toegang krijgen tot een back-endwebservice. In dit geval kan de webtoepassing een iets andere OpenID Connect-stroom uitvoeren en tokens verkrijgen met behulp van autorisatiecodes en vernieuwingstokens. Dit scenario wordt weergegeven in de volgende sectie web-API's.

Toepassingen met één pagina

Veel moderne webtoepassingen zijn gebouwd als toepassingen met één pagina aan de clientzijde ('SPA's'). Ontwikkelaars schrijven ze met behulp van JavaScript of een SPA-framework zoals Angular, Vue of React. Deze toepassingen worden uitgevoerd in een webbrowser en hebben verschillende verificatiekenmerken dan traditionele webtoepassingen aan de serverzijde.

Azure AD B2C biedt twee opties waarmee toepassingen met één pagina gebruikers kunnen aanmelden en tokens kunnen krijgen voor toegang tot back-endservices of web-API's:

Autorisatiecodestroom (met PKCE)

Met OAuth 2.0-autorisatiecodestroom (met PKCE) kan de toepassing een autorisatiecode uitwisselen voor id-tokens om de geverifieerde gebruikers- en toegangstokens weer te geven die nodig zijn om beveiligde API's aan te roepen. Daarnaast worden vernieuwingstokens geretourneerd die langdurige toegang bieden tot resources namens gebruikers zonder tussenkomst van die gebruikers.

We raden deze aanpak aan. Met tokens van beperkte levensduur kan uw toepassing zich aanpassen aan moderne browser-cookie-privacybeperkingen, zoals Safari ITP.

Als u wilt profiteren van deze stroom, kan uw toepassing gebruikmaken van een verificatiebibliotheek die dit ondersteunt, zoals MSAL.js 2.x.

Impliciete toekenningsstroom

Sommige bibliotheken, zoals MSAL.js 1.x, ondersteunen alleen de impliciete toekenningsstroom of uw toepassing is geïmplementeerd om impliciete stroom te gebruiken. In deze gevallen ondersteunt Azure AD B2C de impliciete OAuth 2.0-stroom. Met de impliciete toekenningsstroom kan de toepassing id- en toegangstokens ophalen. In tegenstelling tot de autorisatiecode stroom retourneert de impliciete toekenningsstroom geen refreshtoken.

Deze verificatiestroom bevat geen toepassingsscenario's die gebruikmaken van platformoverschrijdende JavaScript-frameworks zoals Electron en React-Native. Deze scenario's vereisen verdere mogelijkheden voor interactie met de systeemeigen platforms.

Waarschuwing

Microsoft raadt u aan de impliciete toekenningsstroom niet te gebruiken. De aanbevolen manier om SPA's te ondersteunen, is OAuth 2.0-autorisatiecodestroom (met PKCE). Bepaalde configuraties van deze stroom vereisen een zeer hoge mate van vertrouwen in de toepassing en dragen risico's die niet aanwezig zijn in andere stromen. U moet deze stroom alleen gebruiken wanneer andere veiligere stromen niet haalbaar zijn. Zie de beveiligingsproblemen met impliciete toekenningsstroom voor meer informatie.

Web API's

U kunt Azure AD B2C gebruiken om webservices, zoals de RESTful-web-API van uw toepassing, te beveiligen. Web-API's kunnen OAuth 2.0 gebruiken om hun gegevens te beveiligen door binnenkomende HTTP-aanvragen te verifiëren met behulp van tokens. De aanroeper van een web-API voegt een token toe aan de autorisatieheader van een HTTP-aanvraag:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

De web-API kan vervolgens het token gebruiken om de identiteit van de API-aanroeper te verifiëren en informatie te extraheren over de aanroeper van claims die zijn gecodeerd in het token. Meer informatie over de typen tokens en claims die beschikbaar zijn voor een app in de Azure AD B2C-tokenreferentie.

Een web-API kan tokens ontvangen van veel soorten clients, waaronder webtoepassingen, desktop- en mobiele toepassingen, toepassingen met één pagina, daemons aan de serverzijde en andere web-API's. Hier volgt een voorbeeld van de volledige stroom voor een webtoepassing die een web-API aanroept:

1. De webtoepassing voert een beleid uit en de gebruiker voltooit de gebruikerservaring.
2. Azure AD B2C retourneert een (OpenID Connect) id_token en een autorisatiecode naar de browser.
3. De browser plaatst de id_token en autorisatiecode op de omleidings-URI.
4. De webserver valideert het id_token en stelt een sessiecooky in.
5. De webserver vraagt Azure AD B2C om een access_token aanvraag door deze op te geven met de autorisatiecode, toepassingsclient-id en clientreferenties.
6. De access_token en refresh_token worden geretourneerd naar de webserver.
7. De web-API wordt aangeroepen met de access_token in een autorisatieheader.
8. De web-API valideert het token.
9. Beveiligde gegevens worden geretourneerd naar de webtoepassing.

Lees voor meer informatie over autorisatiecodes, vernieuwingstokens en de stappen voor het ophalen van tokens over het OAuth 2.0-protocol.

Als u wilt weten hoe u een web-API beveiligt met behulp van Azure AD B2C, raadpleegt u de zelfstudies voor web-API's in de sectie Aan de slag.

Mobiele en systeemeigen toepassingen

Toepassingen die zijn geïnstalleerd op apparaten, zoals mobiele en bureaubladtoepassingen, moeten vaak namens gebruikers toegang hebben tot back-endservices of web-API's. U kunt aangepaste identiteitsbeheerervaringen toevoegen aan uw systeemeigen toepassingen en back-endservices veilig aanroepen met behulp van Azure AD B2C en de OAuth 2.0-autorisatiecodestroom.

In deze stroom voert de toepassing beleidsregels uit en ontvangt deze een authorization_code van Microsoft Entra ID nadat de gebruiker de beleidsregel heeft voltooid. Deze authorization_code vertegenwoordigt de machtiging van de toepassing om back-endservices aan te roepen namens de gebruiker die momenteel is aangemeld. De toepassing kan vervolgens authorization_code op de achtergrond uitwisselen voor een access_token en een refresh_token. De toepassing kan de access_token gebruiken om te authenticeren bij een back-endweb-API in HTTP-aanvragen. Het kan ook de refresh_token functie gebruiken om een nieuwe access_token te krijgen wanneer een oudere verloopt.

Daemons/toepassingen aan de serverzijde

Toepassingen die langlopende processen bevatten of die werken zonder de aanwezigheid van een gebruiker, hebben ook een manier nodig om toegang te krijgen tot beveiligde resources, zoals web-API's. Deze toepassingen kunnen tokens verifiëren en ophalen met behulp van hun identiteiten (in plaats van de gedelegeerde identiteit van een gebruiker) en met behulp van de OAuth 2.0-clientreferentiestroom. De client-aanmeldingsstroom is niet hetzelfde als de on-behalf-flow en de on-behalf-flow mag niet worden gebruikt voor server-naar-serverauthenticatie.

Voor Azure AD B2C is de OAuth 2.0-clientreferentiestroom momenteel in openbare preview. U kunt echter de clientreferentiestroom instellen met behulp van Microsoft Entra ID en het Microsoft Identity Platform-eindpunt /token (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) voor een Microsoft Graph-toepassing of uw eigen toepassing. Raadpleeg het microsoft Entra-tokenreferentieartikel voor meer informatie.

Niet-ondersteunde toepassingstypen

Web-API-ketens (namens-verwerkingsstroom)

Veel architecturen bevatten een web-API die een andere downstream-web-API moet aanroepen, waarbij beide worden beveiligd door Azure AD B2C. Dit scenario is gebruikelijk in systeemeigen clients die een web-API-back-end hebben en een Microsoft-onlineservice zoals de Microsoft Graph API aanroept.

Dit gekoppelde web-API-scenario kan worden ondersteund met behulp van de OAuth 2.0 JWT Bearer-referentietoekenning, ook wel bekend als de on-behalf-of-flow. De on-behalf-of-flow wordt momenteel echter niet geïmplementeerd in Azure AD B2C.

Volgende stappen

Meer informatie over het ingebouwde beleid dat wordt geleverd door gebruikersstromen in Azure Active Directory B2C.