Toepassingstypen die kunnen worden gebruikt in Active Directory B2C

  • Artikel

Azure Active Directory B2C (Azure AD B2C) ondersteunt verificatie voor verschillende moderne toepassingsarchitecturen. Ze zijn allemaal gebaseerd op de protocollen volgens de industrienorm OAuth 2.0 of OpenID Connect. In dit artikel vindt u een korte beschrijving van de typen toepassingen die u kunt maken, onafhankelijk van de taal of het platform waaraan u de voorkeur geeft. Het document geeft ook inzicht in geavanceerde scenario's voordat u toepassingen gaat ontwikkelen.

Elke toepassing die gebruikmaakt van Azure AD B2C moet via Azure Portal zijn geregistreerd in uw Azure AD B2C-tenant. Tijdens het registratieproces voor de toepassing worden er waarden verzameld en toegewezen, zoals:

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

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

De interactie van elke toepassing volgt in grote lijnen hetzelfde patroon:

  1. De toepassing leidt 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 om toegang te krijgen tot beveiligde gegevens of een beveiligde resource.
  5. De resource-server valideert het beveiligingstoken om te controleren of toegang kan worden verleend.
  6. Het beveiligingstoken wordt regelmatig vernieuwd door de toepassing.

Deze stappen kunnen iets verschillen, afhankelijk van het type toepassing dat u maakt.

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 voeren voor Microsoft Entra-id. Het resultaat van de aanvraag is een id_token. Dit beveiligingstoken vertegenwoordigt de identiteit van de gebruiker. Het bevat 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": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

In de Naslaginformatie over Azure AD B2C-tokens vindt u meer informatie over de typen tokens en claims die beschikbaar zijn voor een toepassing.

In een webtoepassing bestaat de uitvoering van een beleid uit de volgende globale stappen:

  1. De gebruiker bladert naar de webtoepassing.
  2. De webtoepassing leidt de gebruiker om naar Azure AD B2C die aangeeft welk beleid moet worden uitgevoerd.
  3. De gebruiker voltooit het beleid.
  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 wordt gevalideerd en er wordt een sessiecooky ingesteld.
  7. Er wordt een beveiligde pagina geretourneerd naar de gebruiker.

Validatie van de id_token met behulp van een openbare ondertekeningssleutel die is ontvangen van Microsoft Entra id is voldoende om de identiteit van de gebruiker te verifiëren. Hiermee wordt ook een sessiecookie ingesteld waarmee de gebruiker bij volgende pagina-aanvragen kan worden geïdentificeerd.

Als u wilt zien hoe dit scenario werkt, probeer dan een van de codevoorbeelden van webtoepassing-aanmelding in de sectie Aan de slag.

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

Toepassingen met één pagina

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

Azure AD B2C biedt twee opties om toepassingen met één pagina te gebruiken om gebruikers aan te melden en tokens op te halen voor toegang tot back-endservices of web-API’s:

Autorisatiecodestroom (met PKCE)

Met de OAuth 2.0 autorisatiecodestroom (met PKCE) kan de toepassing een autorisatiecode uitwisselen voor id-tokens om de geverifieerde gebruiker te vertegenwoordigen, en de benodigde toegangstokens om beveiligde API’s aan te roepen. Daarnaast worden met deze stroom vernieuwingstokens geretourneerd, die namens gebruikers langetermijntoegang bieden tot resources, zonder dat interactie met deze gebruikers is vereist.

We raden deze aanpak aan. Vernieuwingstokens met een beperkte levensduur helpen om uw toepassing aan te passen aan de privacybeperkingen van cookies van de moderne browser, zoals Safari ITP.

De toepassing kan een verificatiebibliotheek gebruiken, zoals MSAL.js 2.x om te profiteren van deze stroom.

Toepassingen met één pagina - verificatie

Impliciete toekenningsstroom

Sommige bibliotheken, zoals MSAL.js 1.x, ondersteunen alleen de impliciete toekenningsstroom. Of uw toepassing wordt geïmplementeerd om impliciete stroom te gebruiken. In deze gevallen ondersteunt Azure AD B2C de impliciete OAuth 2.0-stroom. De impliciete toekenningsstroom stelt de toepassing in staat om id-tokens en toegangstokens op te halen. In tegenstelling tot de autorisatiecodestroom retourneert de impliciete toekenningsstroom geen vernieuwingstoken.

We bevelen deze aanpak niet aan.

In deze verificatiestroom zijn geen toepassingsscenario's opgenomen waarin wordt gebruikgemaakt van platformoverschrijdende JavaScript-frameworks, zoals Electron en React-Native. Deze scenario's vereisen extra mogelijkheden voor interactie met de systeemeigen platformen.

Web-API's

U kunt Azure AD B2C gebruiken om webservices te beveiligen, zoals de RESTful-web-API van uw toepassing. Web-API's kunnen OAuth 2.0 gebruiken om hun gegevens te beveiligen door verificatie van binnenkomende HTTP-aanvragen via tokens. De aanroeper van een web-API voegt een token toe in de autorisatie-header van een HTTP-aanvraag:

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

De web-API kan het token vervolgens gebruiken om de identiteit van de API-aanroeper te verifiëren en om informatie over de aanroeper af te leiden uit de claims die in het token zijn gecodeerd. In de Naslaginformatie over Azure AD B2C-tokens vindt u meer informatie over de typen tokens en claims die beschikbaar zijn voor een app.

Een web-API kan tokens ontvangen van tal van clients, waaronder webtoepassingen, bureaublad- en mobiele toepassingen, toepassingen van één pagina, daemons aan 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 de autorisatiecode, toepassingsclient-id en clientreferenties op te geven.
  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.

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

Voor meer informatie over het beveiligen van een web-API met behulp van Azure AD B2C bekijkt u de web-API-zelfstudies in de sectie Aan de slag.

Mobiele en systeemeigen toepassingen

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

In deze stroom voert de toepassing beleidsregels uit en ontvangt een authorization_code van Microsoft Entra-id nadat de gebruiker het beleid heeft voltooid. De authorization_code vertegenwoordigt de machtiging van de toepassingen om back-endservices aan te roepen namens de gebruiker die op dat moment is aangemeld. De toepassing kan vervolgens op de achtergrond de authorization_code uitwisselen voor een access_token en een refresh_token. De toepassing kan de access_token gebruiken om een back-end-web-API in HTTP-aanvragen te verifiëren. Het refresh_token kan ook worden gebruikt om nieuwe access_token te verkrijgen wanneer de oudere zijn verlopen.

Daemons/toepassingen aan serverzijde

Ook toepassingen die langlopende processen bevatten of die werken zonder de aanwezigheid van een gebruiker, hebben een manier nodig om toegang te krijgen tot beveiligde resources, zoals web-API's. Deze toepassingen kunnen tokens verifiëren en verkrijgen door de identiteiten te gebruiken (in plaats van een gedelegeerde gebruikersidentiteit) en door de referentiestroom van de OAuth 2.0-client te gebruiken. Clientreferentiestroom is niet hetzelfde als on-behalf-flow en on-behalf-flow mag niet worden gebruikt voor server-naar-serververificatie.

Voor Azure AD B2C is de OAuth 2.0-clientreferentiestroom momenteel beschikbaar als 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 artikel naslaginformatie over Microsoft Entra token voor meer informatie.

Niet-ondersteunde toepassingstypen

Web-API-ketens (namens-stroom)

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

Dit scenario met web-API-keten kan worden ondersteund met behulp van de OAuth 2.0 JWT bearer-referentietoekenning, ook wel de namens-stroom genoemd. De namens-stroom is momenteel echter niet geïmplementeerd in Azure AD B2C.

Volgende stappen

Meer informatie over het ingebouwde beleidsregels die worden geleverd door gebruikersstromen in Azure Active Directory B2C.