Web-aanmelding met OpenID-Verbinding maken in Azure Active Directory B2C
OpenID Verbinding maken is een verificatieprotocol dat is gebouwd boven op OAuth 2.0, dat kan worden gebruikt om gebruikers veilig aan te melden bij webtoepassingen. Met behulp van de Azure Active Directory B2C-implementatie (Azure AD B2C) van OpenID Verbinding maken kunt u registratie, aanmelding en andere identiteitsbeheerervaringen in uw webtoepassingen uitbesteden aan Microsoft Entra ID. In deze handleiding ziet u hoe u dit op een taalonafhankelijke manier kunt doen. Hierin wordt beschreven hoe u HTTP-berichten verzendt en ontvangt zonder gebruik te maken van onze opensource-bibliotheken.
Notitie
De meeste opensource-verificatiebibliotheken verkrijgen en valideren de JWT-tokens voor uw toepassing. We raden u aan deze opties te verkennen in plaats van uw eigen code te implementeren. Zie Overzicht van de Microsoft Authentication Library (MSAL) en microsoft Identity Web Authentication Library (Microsoft Identity Web Authentication Library) voor meer informatie.
OpenID Verbinding maken breidt het OAuth 2.0-autorisatieprotocol uit voor gebruik als verificatieprotocol. Met dit verificatieprotocol kunt u eenmalige aanmelding uitvoeren. Het introduceert het concept van een id-token, waarmee de client de identiteit van de gebruiker kan verifiëren en basisprofielgegevens over de gebruiker kan verkrijgen.
Met OpenID Verbinding maken kunnen toepassingen ook veilig toegangstokens verkrijgen. U kunt toegangstokens gebruiken om toegang te krijgen tot resources die door de autorisatieserver worden beveiligd. We raden OpenID Verbinding maken aan als u een webtoepassing bouwt die u op een server host en toegankelijk is via een browser. Zie het overzicht van tokens in Azure Active Directory B2C voor meer informatie over tokens
Azure AD B2C breidt het standaard OpenID-Verbinding maken-protocol uit om meer te doen dan eenvoudige verificatie en autorisatie. Hiermee maakt u kennis met de parameter gebruikersstroom, waarmee u OpenID Verbinding maken kunt gebruiken om gebruikerservaringen toe te voegen aan uw toepassing, zoals registreren, aanmelden en profielbeheer.
Verificatieaanvragen verzenden
Wanneer uw webtoepassing de gebruiker moet verifiëren en een gebruikersstroom moet uitvoeren, kan deze de gebruiker doorsturen naar het /authorize
eindpunt. De gebruiker neemt actie, afhankelijk van de gebruikersstroom.
In deze aanvraag geeft de client de machtigingen aan die deze moet verkrijgen van de gebruiker in de scope
parameter en geeft de gebruikersstroom op die moet worden uitgevoerd. Als u wilt zien hoe de aanvraag werkt, plakt u de aanvraag in uw browser en voert u deze uit. Vervangen:
{tenant}
met de naam van uw tenant.90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
met de app-id van een toepassing die u hebt geregistreerd in uw tenant.{application-id-uri}/{scope-name}
met de URI van de toepassings-id en het bereik van een toepassing die u hebt geregistreerd in uw tenant.{policy}
met de beleidsnaam die u in uw tenant hebt, bijvoorbeeldb2c_1_sign_in
.
GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
Parameter | Vereist | Beschrijving |
---|---|---|
{tenant} | Ja | Naam van uw Azure AD B2C-tenant. Als u een aangepast domein gebruikt, vervangt u dit door tenant.b2clogin.com uw domein, zoals fabrikam.com . |
{policy} | Ja | De gebruikersstroom of het beleid dat door de app wordt uitgevoerd. Geef de naam op van een gebruikersstroom die u maakt in uw Azure AD B2C-tenant. Bijvoorbeeld: b2c_1_sign_in , b2c_1_sign_up of b2c_1_edit_profile . |
client_id | Ja | De toepassings-id die de Azure-portal heeft toegewezen aan uw toepassing. |
nonce | Ja | Een waarde die is opgenomen in de aanvraag (gegenereerd door de toepassing) die als claim is opgenomen in het resulterende id-token. De toepassing kan deze waarde vervolgens controleren om het opnieuw afspelen van tokens te beperken. De waarde is doorgaans een gerandomiseerde unieke tekenreeks die kan worden gebruikt om de oorsprong van de aanvraag te identificeren. |
response_type | Ja | Moet een id-token bevatten voor OpenID-Verbinding maken. Als uw webtoepassing ook tokens nodig heeft voor het aanroepen van een web-API, kunt u dit gebruiken code+id_token . |
bereik | Ja | Een door spaties gescheiden lijst van bereiken. Het openid bereik geeft een machtiging aan om de gebruiker aan te melden en gegevens over de gebruiker op te halen in de vorm van id-tokens. Het offline_access bereik is optioneel voor webtoepassingen. Het geeft aan dat uw toepassing een vernieuwingstoken nodig heeft voor uitgebreide toegang tot resources. Hiermee https://{tenant-name}/{app-id-uri}/{scope} wordt een machtiging voor beveiligde resources aangegeven, zoals een web-API. Zie Een toegangstoken aanvragen voor meer informatie. |
vraag | Nee | Het type gebruikersinteractie dat u nodig hebt. De enige geldige waarde op dit moment is login , waardoor de gebruiker zijn referenties voor die aanvraag invoert. |
redirect_uri | Ja | De redirect_uri parameter van uw toepassing, waarbij de server verificatiereacties naar uw toepassing verzendt. Deze moet exact overeenkomen met een van de redirect_uri parameters die u hebt geregistreerd in Azure Portal, behalve dat deze URL-gecodeerd moet zijn. |
response_mode | Nee | De methode die wordt gebruikt om de resulterende autorisatiecode terug te sturen naar uw toepassing. Het kan ofwel query , form_post of fragment . We raden u aan de form_post responsmodus te gebruiken voor de beste beveiliging. |
staat | Nee | Een waarde die u kunt opnemen in de aanvraag die de autorisatieserver retourneert in het tokenantwoord. Het kan een tekenreeks zijn van alle gewenste inhoud. Een willekeurig gegenereerde unieke waarde wordt doorgaans gebruikt voor om aanvallen van aanvraagvervalsing op meerdere sites te voorkomen. De status wordt ook gebruikt om informatie over de status van de gebruiker in de toepassing te coderen voordat de verificatieaanvraag is opgetreden, zoals de pagina waarop ze zich bevonden. Als u niet meerdere omleidings-URL's wilt registreren in Azure Portal, kunt u de state parameter gebruiken om reacties in uw toepassing te onderscheiden van de Azure AD B2C-service vanwege verschillende aanvragen. |
login_hint | Nee | Kan worden gebruikt om het aanmeldingsnaamveld van de aanmeldingspagina vooraf in te vullen. Zie De aanmeldingsnaam vooraf invullen voor meer informatie. |
domain_hint | Nee | Biedt een hint voor Azure AD B2C over de id-provider voor sociale netwerken die moet worden gebruikt voor aanmelding. Als er een geldige waarde is opgenomen, gaat de gebruiker rechtstreeks naar de aanmeldingspagina van de id-provider. Zie Aanmelden omleiden naar een sociale provider voor meer informatie. |
Aangepaste parameters | Nee | Aangepaste parameters die kunnen worden gebruikt met aangepast beleid. Bijvoorbeeld dynamische aangepaste pagina-inhouds-URI of sleutelwaarde claim resolvers. |
Op dit moment wordt de gebruiker gevraagd de werkstroom te voltooien. De gebruiker moet mogelijk zijn of haar gebruikersnaam en wachtwoord invoeren, zich aanmelden met een sociale identiteit of zich aanmelden voor de directory. Er kan een ander aantal stappen zijn, afhankelijk van de manier waarop de gebruikersstroom is gedefinieerd.
Nadat de gebruiker de gebruikersstroom heeft voltooid, wordt er een antwoord geretourneerd naar uw toepassing op de aangegeven redirect_uri
parameter met behulp van de methode die u in de response_mode
parameter opgeeft. Het antwoord is hetzelfde voor elk van de voorgaande gevallen, onafhankelijk van de gebruikersstroom.
Een geslaagd antwoord dat wordt gebruikt response_mode=fragment
, ziet er als volgt uit:
GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
Parameter | Description |
---|---|
id_token | Het id-token dat de toepassing heeft aangevraagd. U kunt de id-token gebruiken om de identiteit van de gebruiker te controleren en een sessie met de gebruiker te starten. |
code | De autorisatiecode die de toepassing heeft aangevraagd, als u deze hebt gebruikt response_type=code+id_token . De toepassing kan de autorisatiecode gebruiken om een toegangstoken aan te vragen voor een doelresource. Autorisatiecodes verlopen doorgaans na ongeveer 10 minuten. |
staat | Als een state -parameter is opgenomen in de aanvraag, zou dezelfde waarde moeten verschijnen in de reactie. De toepassing moet controleren of de state waarden in de aanvraag en het antwoord identiek zijn. |
Foutreacties kunnen ook naar de redirect_uri
parameter worden verzonden, zodat de toepassing deze op de juiste manier kan verwerken:
GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response
Parameter | Description |
---|---|
error | Een code die kan worden gebruikt om de typen fouten te classificeren die optreden. |
error_description | Een specifiek foutbericht waarmee de hoofdoorzaak van een verificatiefout kan worden geïdentificeerd. |
staat | Als een state -parameter is opgenomen in de aanvraag, zou dezelfde waarde moeten verschijnen in de reactie. De toepassing moet controleren of de state waarden in de aanvraag en het antwoord identiek zijn. |
De id-token valideren
Het ontvangen van een id-token is niet voldoende om de gebruiker te verifiëren. Valideer de handtekening van het id-token en controleer de claims in het token volgens de vereisten van uw toepassing. Azure AD B2C maakt gebruik van JSON-webtokens (JWTs) en openbare-sleutelcryptografie om tokens te ondertekenen en te controleren of ze geldig zijn.
Notitie
De meeste opensource-verificatiebibliotheken valideren de JWT-tokens voor uw toepassing. We raden u aan deze opties te verkennen in plaats van uw eigen validatielogica te implementeren. Zie Overzicht van de Microsoft Authentication Library (MSAL) en microsoft Identity Web Authentication Library (Microsoft Identity Web Authentication Library) voor meer informatie.
Azure AD B2C heeft een OpenID Verbinding maken metagegevenseindpunt, waarmee een toepassing tijdens runtime informatie over Azure AD B2C kan ophalen. Deze informatie omvat eindpunten, inhoud van tokens en tokenondertekeningssleutels. Er is een JSON-metagegevensdocument voor elke gebruikersstroom in uw B2C-tenant. Het metagegevensdocument voor de b2c_1_sign_in
gebruikersstroom bevindt fabrikamb2c.onmicrosoft.com
zich bijvoorbeeld op:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
Een van de eigenschappen van dit configuratiedocument is jwks_uri
, waarvan de waarde voor dezelfde gebruikersstroom zou zijn:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
U hebt twee opties om te bepalen welke gebruikersstroom is gebruikt om een id-token te ondertekenen. Eerst wordt de naam van de gebruikersstroom opgenomen in de acr
claim in het id-token, zie de claim die de gebruikersstroom vertegenwoordigt. U kunt de gebruikersstroom ook coderen in de waarde van de state
parameter wanneer u de aanvraag verzendt en deze vervolgens decoderen om te bepalen welke gebruikersstroom is gebruikt. Beide methoden zijn geldig.
Nadat u het metagegevensdocument hebt verkregen van het OpenID-Verbinding maken-eindpunt voor metagegevens, kunt u de openbare RSA 256-sleutels gebruiken om de handtekening van het id-token te valideren. Er kunnen meerdere sleutels worden vermeld op dit eindpunt, elk geïdentificeerd door een kid
claim. De header van het id-token bevat ook een kid
claim, die aangeeft welke van deze sleutels is gebruikt om het id-token te ondertekenen.
Als u de tokens van Azure AD B2C wilt controleren, moet u de openbare sleutel genereren met behulp van de exponent(e) en modulus(n). Hiervoor moet u leren hoe u de openbare sleutel genereert in een programmeertaal van uw keuze. De officiële documentatie over het genereren van openbare sleutels met het RSA-protocol vindt u hier: https://tools.ietf.org/html/rfc3447#section-3.1
Nadat u de handtekening van het id-token hebt gevalideerd, zijn er verschillende claims die u moet verifiëren. Bijvoorbeeld:
- Valideer de
nonce
claim om herhalingsaanvallen van tokens te voorkomen. De waarde moet zijn wat u hebt opgegeven in de aanmeldingsaanvraag. - Valideer de
aud
claim om ervoor te zorgen dat het id-token is uitgegeven voor uw toepassing. De waarde moet de toepassings-id van uw toepassing zijn. - Valideer de
iat
enexp
claims om ervoor te zorgen dat het id-token niet is verlopen.
Er zijn ook nog enkele validaties die u moet uitvoeren. De validaties worden gedetailleerd beschreven in de OpenID Verbinding maken Core Spec. Mogelijk wilt u ook meer claims valideren, afhankelijk van uw scenario. Enkele vaak voorkomende validaties omvatten:
- Zorg ervoor dat de gebruiker/organisatie zich heeft geregistreerd voor de toepassing.
- Zorg ervoor dat de gebruiker over de juiste autorisatie/bevoegdheden beschikt.
- Zorg ervoor dat er een bepaalde verificatiesterkte is opgetreden, zoals Meervoudige Verificatie van Microsoft Entra.
Nadat het id-token is gevalideerd, kunt u een sessie met de gebruiker starten. U kunt de claims in het id-token gebruiken om informatie over de gebruiker in uw toepassing te verkrijgen. Wordt gebruikt voor deze informatie zijn weergave, records en autorisatie.
Een token ophalen
Als u uw webtoepassing nodig hebt om alleen gebruikersstromen uit te voeren, kunt u de volgende secties overslaan. Deze secties zijn alleen van toepassing op webtoepassingen die geverifieerde aanroepen moeten doen naar een web-API, die wordt beveiligd door Azure AD B2C zelf.
U kunt de autorisatiecode die u hebt verkregen (met behulp van response_type=code+id_token
) voor een token inwisselen naar de gewenste resource door een POST
aanvraag naar het /token
eindpunt te verzenden. In Azure AD B2C kunt u zoals gebruikelijk toegangstokens aanvragen voor andere API's door hun bereik(en ) in de aanvraag op te geven.
U kunt ook een toegangstoken aanvragen voor de eigen back-endweb-API van uw app. In dit geval gebruikt u de client-id van de app als het aangevraagde bereik, wat resulteert in een toegangstoken met die client-id als de 'doelgroep':
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parameter | Vereist | Beschrijving |
---|---|---|
{tenant} | Ja | Naam van uw Azure AD B2C-tenant |
{policy} | Ja | De gebruikersstroom die is gebruikt om de autorisatiecode te verkrijgen. U kunt in deze aanvraag geen andere gebruikersstroom gebruiken. Voeg deze parameter toe aan de querytekenreeks, niet aan de POST-hoofdtekst. |
client_id | Ja | De toepassings-id die de Azure-portal heeft toegewezen aan uw toepassing. |
client_secret | Ja, in Web Apps | Het toepassingsgeheim dat is gegenereerd in Azure Portal. Clientgeheimen worden gebruikt in deze stroom voor web-app-scenario's, waarbij de client veilig een clientgeheim kan opslaan. Voor systeemeigen app-scenario's (openbare client) kunnen clientgeheimen niet veilig worden opgeslagen, dus niet gebruikt voor deze stroom. Als u een clientgeheim gebruikt, wijzigt u het periodiek. |
code | Ja | De autorisatiecode die u hebt verkregen aan het begin van de gebruikersstroom. |
grant_type | Ja | Het type toekenning, dat moet zijn authorization_code voor de autorisatiecodestroom. |
redirect_uri | Nee | De redirect_uri parameter van de toepassing waar u de autorisatiecode hebt ontvangen. |
bereik | Nee | Een door spaties gescheiden lijst van bereiken. Het openid bereik geeft een machtiging aan om de gebruiker aan te melden en gegevens over de gebruiker op te halen in de vorm van id_token parameters. Het kan worden gebruikt om tokens op te halen naar de eigen back-endweb-API van uw toepassing, die wordt vertegenwoordigd door dezelfde toepassings-id als de client. Het offline_access bereik geeft aan dat uw toepassing een vernieuwingstoken nodig heeft voor uitgebreide toegang tot resources. |
Een geslaagd tokenantwoord ziet er als volgt uit:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
"expires_in": "3600",
"expires_on": "1644254945",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parameter | Description |
---|---|
not_before | Het tijdstip waarop het token geldig wordt. |
token_type | De waarde van het tokentype. Bearer is het enige type dat wordt ondersteund. |
access_token | Het ondertekende JWT-token dat u hebt aangevraagd. |
bereik | De geldige bereiken voor het token. |
expires_in | De tijdsduur waarop het toegangstoken geldig is (in seconden). |
expires_on | Het tijdstip waarop het toegangstoken ongeldig wordt. |
refresh_token | Een OAuth 2.0-vernieuwingstoken. De toepassing kan dit token gebruiken om meer tokens te verkrijgen nadat het huidige token is verlopen. Vernieuwingstokens kunnen worden gebruikt om de toegang tot resources gedurende langere tijd te behouden. Het bereik offline_access moet zijn gebruikt in zowel de autorisatie- als tokenaanvragen om een vernieuwingstoken te kunnen ontvangen. |
Foutberichten zien er als volgt uit:
{
"error": "invalid_grant",
"error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}
Parameter | Description |
---|---|
error | Een code die kan worden gebruikt om typen fouten te classificeren die optreden. |
error_description | Een bericht dat kan helpen bij het identificeren van de hoofdoorzaak van een verificatiefout. |
Het token gebruiken
Nadat u een toegangstoken hebt verkregen, kunt u het token gebruiken in aanvragen voor uw back-endweb-API's door het op te nemen in de Authorization
header:
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
Het token vernieuwen
Toegangstokens en id-tokens zijn kortlevend. Nadat ze zijn verlopen, moet u ze vernieuwen om toegang te blijven krijgen tot resources. Wanneer u het toegangstoken vernieuwt, retourneert Azure AD B2C een nieuw token. Het vernieuwde toegangstoken heeft de claimwaarden bijgewerkt nbf
(niet eerder), iat
(uitgegeven op) en exp
(vervaldatum). Alle andere claimwaarden zijn vergelijkbaar met die in het vorige toegangstoken.
Vernieuw een token door een andere POST
aanvraag naar het /token
eindpunt te verzenden. Geef deze keer de refresh_token
parameter op in plaats van de code
parameter:
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parameter | Vereist | Beschrijving |
---|---|---|
{tenant} | Ja | Naam van uw Azure AD B2C-tenant |
{policy} | Ja | De gebruikersstroom die is gebruikt om het oorspronkelijke vernieuwingstoken te verkrijgen. U kunt in deze aanvraag geen andere gebruikersstroom gebruiken. Voeg deze parameter toe aan de querytekenreeks, niet aan de POST-hoofdtekst. |
client_id | Ja | De toepassings-id die de Azure-portal heeft toegewezen aan uw toepassing. |
client_secret | Ja, in Web Apps | Het toepassingsgeheim dat is gegenereerd in Azure Portal. Clientgeheimen worden gebruikt in deze stroom voor web-app-scenario's, waarbij de client veilig een clientgeheim kan opslaan. Voor systeemeigen app-scenario's (openbare client) kunnen clientgeheimen niet veilig worden opgeslagen, dus niet gebruikt voor deze aanroep. Als u een clientgeheim gebruikt, wijzigt u dit periodiek. |
grant_type | Ja | Het type toekenning, dat voor dit deel van de autorisatiecodestroom moet zijn refresh_token . |
refresh_token | Ja | Het oorspronkelijke vernieuwingstoken dat is verkregen in het tweede deel van de stroom. Het offline_access bereik moet worden gebruikt in zowel de autorisatie- als tokenaanvragen om een vernieuwingstoken te ontvangen. |
redirect_uri | Nee | De redirect_uri parameter van de toepassing waar u de autorisatiecode hebt ontvangen. |
bereik | Nee | Een door spaties gescheiden lijst van bereiken. Het openid bereik geeft een machtiging aan om de gebruiker aan te melden en gegevens over de gebruiker op te halen in de vorm van id-tokens. Het kan worden gebruikt om tokens te verzenden naar de eigen back-endweb-API van uw toepassing, die wordt vertegenwoordigd door dezelfde toepassings-id als de client. Het offline_access bereik geeft aan dat uw toepassing een vernieuwingstoken nodig heeft voor uitgebreide toegang tot resources. |
Een geslaagd tokenantwoord ziet er als volgt uit:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
"refresh_token_expires_in": "1209600"
}
Parameter | Description |
---|---|
not_before | Het tijdstip waarop het token geldig wordt. |
token_type | De waarde van het tokentype. Bearer is het enige type dat wordt ondersteund. |
access_token | Het ondertekende JWT-token dat is aangevraagd. |
bereik | De geldige bereiken voor het token. |
expires_in | De tijdsduur waarop het toegangstoken geldig is (in seconden). |
refresh_token | Een OAuth 2.0-vernieuwingstoken. De toepassing kan dit token gebruiken om extra tokens te verkrijgen nadat het huidige token is verlopen. Vernieuwingstokens kunnen worden gebruikt om de toegang tot resources gedurende langere tijd te behouden. |
refresh_token_expires_in | De tijdsduur waarop het vernieuwingstoken geldig is (in seconden). |
Foutberichten zien er als volgt uit:
{
"error": "invalid_grant",
"error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}
Parameter | Description |
---|---|
error | Een code die kan worden gebruikt om typen fouten te classificeren die optreden. |
error_description | Een bericht dat kan helpen bij het identificeren van de hoofdoorzaak van een verificatiefout. |
Een afmeldingsaanvraag verzenden
Wanneer u de gebruiker wilt afmelden bij de toepassing, is het niet voldoende om de cookies van de toepassing te wissen of de sessie met de gebruiker op een andere manier te beëindigen. De gebruiker omleiden naar Azure AD B2C om zich af te melden. Als u dit niet doet, kan de gebruiker mogelijk opnieuw verifiëren bij uw toepassing zonder de referenties opnieuw in te voeren. Zie het gedrag van Azure AD B2C-sessies voor meer informatie.
Als u de gebruiker wilt afmelden, moet u de gebruiker omleiden naar de end_session_endpoint
gebruiker die wordt vermeld in het OpenID-Verbinding maken metagegevensdocument dat eerder is beschreven:
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
Parameter | Vereist | Beschrijving |
---|---|---|
{tenant} | Ja | Naam van uw Azure AD B2C-tenant. Als u een aangepast domein gebruikt, vervangt u dit door tenant.b2clogin.com uw domein, zoals fabrikam.com . |
{policy} | Ja | De gebruikersstroom die u opgeeft in de autorisatieaanvraag. Als de gebruiker zich bijvoorbeeld heeft aangemeld met de b2c_1_sign_in gebruikersstroom, geeft u b2c_1_sign_in de afmeldingsaanvraag op. |
id_token_hint | Nee | Een eerder uitgegeven id-token om door te geven aan het afmeldingseindpunt als hint over de huidige geverifieerde sessie van de eindgebruiker met de client. Het id_token_hint zorgt ervoor dat het post_logout_redirect_uri een geregistreerde antwoord-URL is in de instellingen van uw Azure AD B2C-toepassing. Zie Uw afmeldingsomleiding beveiligen voor meer informatie. |
client_id | Nee* | De toepassings-id die de Azure-portal heeft toegewezen aan uw toepassing. *Dit is vereist wanneer u de configuratie van Application isolatie-SSO gebruikt en id-token vereisen in afmeldingsaanvraag is ingesteld op No . |
post_logout_redirect_uri | Nee | De URL waarnaar de gebruiker moet worden omgeleid na een geslaagde afmelding. Als deze niet is opgenomen, toont Azure AD B2C de gebruiker een algemeen bericht. Tenzij u een id_token_hint url opgeeft, moet u deze URL niet registreren als antwoord-URL in de instellingen van uw Azure AD B2C-toepassing. |
staat | Nee | Als u een state parameter opneemt in de autorisatieaanvraag, retourneert de autorisatieserver dezelfde waarde in het antwoord op de post_logout_redirect_uri . De toepassing moet controleren of de state waarde in de aanvraag en het antwoord identiek zijn. |
Na een afmeldingsaanvraag wordt in Azure AD B2C de sessie op basis van cookies van Azure AD B2C ongeldig gemaakt en wordt geprobeerd u af te melden bij federatieve id-providers. Zie Eenmalige afmelding voor meer informatie.
Uw afmeldingsomleiding beveiligen
Na afmelding wordt de gebruiker omgeleid naar de URI die u opgeeft in de post_logout_redirect_uri
parameter, ongeacht de antwoord-URL's die u voor de toepassing opgeeft. Als er echter een geldige waarde id_token_hint
wordt doorgegeven en het id-token vereisen in afmeldingsaanvragen is ingeschakeld, controleert Azure AD B2C of de waarde post_logout_redirect_uri
overeenkomt met een van de geconfigureerde omleidings-URI's van de toepassing voordat de omleiding wordt uitgevoerd. Als er geen overeenkomende antwoord-URL is geconfigureerd voor de toepassing, wordt er een foutbericht weergegeven en wordt de gebruiker niet omgeleid.
Zie Sessiegedrag configureren in Azure Active Directory B2C om het vereiste id-token in afmeldingsaanvragen in te stellen.
Volgende stappen
- Meer informatie over Azure AD B2C-sessie.