Azure AD B2C: verificatieprotocollen
Azure Active Directory B2C (Azure AD B2C) biedt identiteit als een service voor uw apps door ondersteuning te bieden voor twee industriestandaardprotocollen: OpenID Connect en OAuth 2.0. De service is compatibel met standaarden, maar verschillende implementaties van deze protocollen kunnen subtiele verschillen hebben.
De informatie in deze handleiding is handig als u uw code schrijft door HTTP-aanvragen rechtstreeks te verzenden en te verwerken, in plaats van een open source-bibliotheek te gebruiken. Het wordt aanbevolen deze pagina te lezen voordat u de details van elk specifiek protocol bekijkt. Maar als u al bekend bent met Azure AD B2C, kunt u rechtstreeks naar de protocolverwijzingsgidsen gaan.
De basisbeginselen
Elke app die gebruikmaakt van Azure AD B2C moet via Azure Portal worden geregistreerd in uw B2C-directory. Tijdens het registratieproces van de app worden enkele waarden verzameld en toegewezen aan uw app:
Een toepassings-id die de app op unieke wijze identificeert.
Een omleidings-URI of pakket-id die kan worden gebruikt om antwoorden naar uw app terug te sturen.
Enkele andere scenariospecifieke waarden. Lees meer over het registreren van uw toepassing voor meer informatie.
Nadat u de app hebt geregistreerd, communiceert deze met Azure AD B2C door verzoeken te sturen naar het eindpunt:
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token
Als u een aangepast domein gebruikt, vervangt u {tenant}.b2clogin.com door het aangepaste domein, zoals contoso.com, in de eindpunten.
In bijna alle OAuth- en OpenID Connect-stromen zijn vier partijen betrokken bij de uitwisseling:
De autorisatieserver is het Azure AD B2C-eindpunt. Het verwerkt veilig alles met betrekking tot gebruikersgegevens en -toegang. Ook wordt de vertrouwensrelaties tussen de partijen in een stroom verwerkt. De server is verantwoordelijk voor het verifiëren van de identiteit van de gebruiker, het verlenen en intrekken van toegang tot resources en het uitgeven van tokens. Staat ook bekend als de identiteitsprovider.
De resource-eigenaar is doorgaans de eindgebruiker. Het is de partij die eigenaar is van de gegevens en de bevoegdheid heeft om derden toegang te geven tot die gegevens of resource.
De OAuth-client is uw app. Deze wordt geïdentificeerd door de bijbehorende toepassings-id. Het is meestal de partij waarmee eindgebruikers communiceren. Er worden ook tokens van de autorisatieserver aangevraagd. De resource-eigenaar moet de client toestemming geven om toegang te krijgen tot de resource.
De resourceserver is de locatie waar de resource of gegevens zich bevinden. De autorisatieserver wordt vertrouwd om de OAuth-client veilig te verifiëren en te autoriseren. Er worden ook bearer-toegangstokens gebruikt om ervoor te zorgen dat toegang tot een resource kan worden verleend.
Beleidsregels en gebruikersstromen
Azure AD B2C breidt de standaard OAuth 2.0- en OpenID Connect-protocollen uit door beleidsregels in te voeren. Hierdoor kan Azure AD B2C veel meer dan eenvoudige verificatie en autorisatie uitvoeren.
Om u te helpen de meest voorkomende identiteitstaken in te stellen, bevat de Azure AD B2C-portal vooraf gedefinieerde, configureerbare beleidsregels, genaamdgebruikersstromen. Gebruikersstromen geven een volledige beschrijving van gebruikersidentiteitservaringen zoals registreren, aanmelden en profielbewerking. Gebruikersstromen kunnen worden gedefinieerd in een gebruikersinterface met beheerdersrechten. Ze kunnen worden uitgevoerd met behulp van een speciale queryparameter in HTTP-verificatieaanvragen.
Beleidsregels en gebruikersstromen zijn geen standaardfuncties van OAuth 2.0 en OpenID Connect, dus neem de tijd om ze te begrijpen. Zie de referentiehandleiding voor Azure AD B2C-gebruikersstromen voor meer informatie.
Tokens
De Azure AD B2C-implementatie van OAuth 2.0 en OpenID Connect maakt uitgebreid gebruik van bearer-tokens, waaronder bearer-tokens die worden weergegeven als JSON-webtokens (JWT's). Een bearer-token is een lichtgewicht beveiligingstoken dat de 'bearer' toegang verleent tot een beveiligde resource.
De bearer is een partij die het token kan presenteren. Azure AD B2C moet eerst een partij verifiëren voordat deze een bearer-token kan ontvangen. Maar als de vereiste stappen niet worden genomen om het token tijdens de overdracht en in opslag te beveiligen, kan het worden onderschept en door een onbedoelde partij worden gebruikt.
Sommige beveiligingstokens hebben ingebouwde mechanismen die verhinderen dat onbevoegde partijen de tokens gebruiken, maar bearer-tokens hebben dit mechanisme niet. Ze moeten worden overgedragen via een beveiligd kanaal, zoals Transport Layer Security (HTTPS).
Als een bearer-token buiten een beveiligd kanaal wordt verzonden, kan een kwaadwillende partij een man-in-the-middle-aanval gebruiken om het token te verkrijgen en te gebruiken om onbevoegde toegang te krijgen tot een beveiligde resource. Dezelfde beveiligingsprincipes zijn van toepassing wanneer bearer-tokens worden opgeslagen of in de cache worden opgeslagen voor later gebruik. Zorg er altijd voor dat uw app bearer-tokens op een veilige manier verzendt en opslaat.
Zie RFC 6750, sectie 5 voor extra beveiligingsoverwegingen voor bearer-tokens.
Meer informatie over de verschillende typen tokens die worden gebruikt in Azure AD B2C zijn beschikbaar in de naslaginformatie over Azure AD B2C-tokens.
Protocollen
Wanneer u klaar bent om enkele voorbeeldaanvragen te bekijken, kunt u beginnen met een van de volgende zelfstudies. Elke zelfstudie komt overeen met een bepaald verificatiescenario. Als u hulp nodig hebt bij het bepalen welke stroom geschikt voor u is, bekijkt u de typen apps die u kunt bouwen met behulp van Azure AD B2C.