Microsoft Identity Platform en OAuth 2.0 On-Behalf-Of-stroom

De OAuth 2.0 On-Behalf-Of-stroom (OBO) dient de use case waarbij een toepassing een service/web-API aanroept, die op zijn beurt een andere service/web-API moet aanroepen. Het idee is om de gedelegeerde gebruikersidentiteit en -machtigingen door te geven via de aanvraagketen. Voor de service in de middelste laag om geverifieerde aanvragen naar de downstreamservice uit te voeren, moet deze namens de gebruiker een toegangstoken beveiligen van het Microsoft-identiteitsplatform.

De OBO-stroom werkt momenteel alleen voor user principals. Een service-principal kan geen token voor alleen apps aanvragen, naar een API verzenden en die API laten uitwisselen voor een ander token dat de oorspronkelijke service-principal vertegenwoordigt. Daarnaast is de OBO-stroom gericht op handelen namens een andere partij, ook wel een gedelegeerd scenario genoemd. Dit betekent dat er alleen gedelegeerde bereiken worden gebruikt, en geen toepassingsrollen, om redeneringen over machtigingen. Rollen blijven gekoppeld aan de principal (de gebruiker) in de stroom, nooit de toepassing die namens de gebruikers wordt uitgevoerd.

In dit artikel wordt beschreven hoe u rechtstreeks kunt programmeren op basis van het protocol in uw toepassing. Indien mogelijk raden we u aan om in plaats daarvan de ondersteunde Microsoft Authentication Libraries (MSAL) te gebruiken om tokens te verkrijgen en beveiligde web-API's aan te roepen. Bekijk ook de voorbeeld-apps die GEBRUIKMAKEN van MSAL.

Tip

Try running this request in Postman
Probeer deze aanvraag uit te voeren en meer in Postman. Vergeet niet om tokens en id's te vervangen.

Clientbeperkingen

Vanaf mei 2018 kan een impliciete stroom id_token niet worden gebruikt voor de OBO-stroom. Apps met één pagina (SPA's) moeten een toegangstoken doorgeven aan een vertrouwelijke client in de middelste laag om in plaats daarvan OBO-stromen uit te voeren.

Als een client de impliciete stroom gebruikt om een id_token op te halen en die client ook jokertekens in een antwoord-URL heeft, kan de id_token niet worden gebruikt voor een OBO-stroom. Toegangstokens die zijn verkregen via de impliciete toekenningsstroom, kunnen echter nog steeds worden ingewisseld door een vertrouwelijke client, zelfs als de initiërende client een antwoord-URL met jokertekens heeft geregistreerd.

Daarnaast kunnen toepassingen met aangepaste ondertekeningssleutels niet worden gebruikt als API's in de middelste laag in de OBO-stroom (dit omvat bedrijfstoepassingen die zijn geconfigureerd voor eenmalige aanmelding). Dit resulteert in een fout omdat tokens die zijn ondertekend met een sleutel die wordt beheerd door de client, niet veilig kunnen worden geaccepteerd.

Protocoldiagram

Stel dat de gebruiker is geverifieerd voor een toepassing met behulp van de OAuth 2.0-autorisatiecodestroom of een andere aanmeldingsstroom. Op dit moment heeft de toepassing een toegangstoken voor API A (token A) met de claims van de gebruiker en toestemming om toegang te krijgen tot de web-API (API A) van de middelste laag. API A moet nu een geverifieerde aanvraag indienen bij de downstream web-API (API B).

De volgende stappen vormen de OBO-stroom en worden uitgelegd met behulp van het volgende diagram.

Shows the OAuth2.0 On-Behalf-Of flow

  1. De clienttoepassing doet een aanvraag naar API A met token A (met een aud claim van API A).
  2. API A wordt geverifieerd bij het eindpunt van de uitgifte van tokens van het Microsoft Identity Platform en vraagt een token aan om toegang te krijgen tot API B.
  3. Het uitgifte-eindpunt van het Microsoft Identity Platform-token valideert de referenties van API A, samen met token A en geeft het toegangstoken voor API B (token B) aan API A uit.
  4. Token B wordt ingesteld door API A in de autorisatieheader van de aanvraag naar API B.
  5. Gegevens van de beveiligde resource worden geretourneerd door API B naar API A en vervolgens naar de client.

In dit scenario heeft de service in de middelste laag geen gebruikersinteractie om toestemming van de gebruiker te krijgen voor toegang tot de downstream-API. Daarom wordt de optie voor het verlenen van toegang tot de downstream-API vooraf weergegeven als onderdeel van de toestemmingsstap tijdens de verificatie. Zie Toestemming verkrijgen voor de toepassing in de middelste laag voor meer informatie over het instellen van deze app.

Aanvraag voor toegangstokens in de middelste laag

Als u een toegangstoken wilt aanvragen, maakt u een HTTP POST naar het tenantspecifieke Microsoft Identity Platform-tokeneindpunt met de volgende parameters.

https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token

Waarschuwing

STUUR GEEN toegangstokens die zijn uitgegeven aan de middelste laag naar een andere partij. Toegangstokens die zijn uitgegeven aan de middelste laag, zijn alleen bedoeld voor gebruik door die middelste laag.

Beveiligingsrisico's voor het doorgeven van toegangstokens van een resource in de middelste laag aan een client (in plaats van de client die de toegangstokens zelf krijgt), zijn onder andere:

  • Verhoogd risico op tokenonderschepping via gecompromitteerde SSL/TLS-kanalen.
  • Het is niet mogelijk om te voldoen aan tokenbindings- en voorwaardelijke toegangsscenario's waarvoor een claim moet worden uitgevoerd (bijvoorbeeld MFA, aanmeldingsfrequentie).
  • Incompatibiliteit met door de beheerder geconfigureerd apparaatbeleid (bijvoorbeeld MDM, beleid op basis van locatie).

Er zijn twee gevallen, afhankelijk van of de clienttoepassing ervoor kiest om te worden beveiligd door een gedeeld geheim of een certificaat.

Eerste geval: Toegangstokenaanvraag met een gedeeld geheim

Wanneer u een gedeeld geheim gebruikt, bevat een service-naar-service-toegangstokenaanvraag de volgende parameters:

Parameter Type Beschrijving
grant_type Vereist Het type tokenaanvraag. Voor een aanvraag met behulp van een JWT moet de waarde zijn urn:ietf:params:oauth:grant-type:jwt-bearer.
client_id Vereist De toepassings-id (client) die de pagina App-registraties heeft toegewezen aan uw app.
client_secret Vereist Het clientgeheim dat u hebt gegenereerd voor uw app in de Azure-portal- pagina App-registraties. Het basisverificatiepatroon van in plaats daarvan referenties in de autorisatieheader op te geven, wordt ook ondersteund per RFC 6749 .
assertion Vereist Het toegangstoken dat is verzonden naar de API voor de middelste laag. Dit token moet een doelgroep (aud) claim hebben van de app die deze OBO-aanvraag doet (de app aangeduid door het client-id veld). Toepassingen kunnen geen token inwisselen voor een andere app (dus als een client een API verzendt die is bedoeld voor MS Graph, kan de API het niet inwisselen met behulp van OBO. In plaats daarvan moet het token worden geweigerd).
scope Vereist Een door spaties gescheiden lijst met bereiken voor de tokenaanvraag. Zie bereiken voor meer informatie.
requested_token_use Vereist Hiermee geeft u op hoe de aanvraag moet worden verwerkt. In de OBO-stroom moet de waarde worden ingesteld op on_behalf_of.

Voorbeeld

De volgende HTTP POST vraagt een toegangstoken aan en vernieuwt token met user.read bereik voor de https://graph.microsoft.com web-API.

//line breaks for legibility only

POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
&client_secret=sampleCredentia1s
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiIyO{a lot of characters here}
&scope=https://graph.microsoft.com/user.read+offline_access
&requested_token_use=on_behalf_of

Tweede geval: Toegangstokenaanvraag met een certificaat

Een service-tokenaanvraag voor toegangstokens met een certificaat bevat de volgende parameters:

Parameter Type Beschrijving
grant_type Vereist Het type tokenaanvraag. Voor een aanvraag met behulp van een JWT moet de waarde zijn urn:ietf:params:oauth:grant-type:jwt-bearer.
client_id Vereist De toepassings-id (client) die de pagina App-registraties heeft toegewezen aan uw app.
client_assertion_type Vereist De waarde moet zijn urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
client_assertion Vereist Een assertie (een JSON-webtoken) die u moet maken en ondertekenen met het certificaat dat u hebt geregistreerd als referenties voor uw toepassing. Zie certificaatreferenties voor meer informatie over het registreren van uw certificaat en de indeling van de assertie.
assertion Vereist Het toegangstoken dat is verzonden naar de API voor de middelste laag. Dit token moet een doelgroep (aud) claim hebben van de app die deze OBO-aanvraag doet (de app aangeduid door het client-id veld). Toepassingen kunnen geen token inwisselen voor een andere app (dus als een client een API verzendt die is bedoeld voor MS Graph, kan de API het niet inwisselen met behulp van OBO. In plaats daarvan moet het token worden geweigerd).
requested_token_use Vereist Hiermee geeft u op hoe de aanvraag moet worden verwerkt. In de OBO-stroom moet de waarde worden ingesteld op on_behalf_of.
scope Vereist Een door spaties gescheiden lijst met bereiken voor de tokenaanvraag. Zie bereiken voor meer informatie.

U ziet dat de parameters bijna hetzelfde zijn als in het geval van de aanvraag door een gedeeld geheim, behalve dat de client_secret parameter wordt vervangen door twee parameters: a client_assertion_type en client_assertion.

Voorbeeld

De volgende HTTP POST vraagt een toegangstoken aan met user.read een bereik voor de https://graph.microsoft.com web-API met een certificaat.

// line breaks for legibility only

POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=625391af-c675-43e5-8e44-edd3e30ceb15
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiO{a lot of characters here}
&requested_token_use=on_behalf_of
&scope=https://graph.microsoft.com/user.read+offline_access

Antwoord op het toegangstoken in de middelste laag

Een geslaagd antwoord is een JSON OAuth 2.0-antwoord met de volgende parameters.

Parameter Beschrijving
token_type Geeft de waarde van het tokentype aan. Het enige type dat door het Microsoft Identity Platform wordt ondersteund, is Bearer. Zie het OAuth 2.0 Authorization Framework: Bearer-tokengebruik (RFC 6750) voor meer informatie over bearer-tokens.
scope Het toegangsbereik dat in het token wordt verleend.
expires_in De tijdsduur, in seconden, dat het toegangstoken geldig is.
access_token Het aangevraagde toegangstoken. De aanroepende service kan dit token gebruiken om te verifiëren bij de ontvangende service.
refresh_token Het vernieuwingstoken voor het aangevraagde toegangstoken. De aanroepende service kan dit token gebruiken om een ander toegangstoken aan te vragen nadat het huidige toegangstoken is verlopen. Het vernieuwingstoken wordt alleen opgegeven als het offline_access bereik is aangevraagd.

Voorbeeld van geslaagde respons

In het volgende voorbeeld ziet u een geslaagd antwoord op een aanvraag voor een toegangstoken voor de https://graph.microsoft.com web-API.

{
  "token_type": "Bearer",
  "scope": "https://graph.microsoft.com/user.read",
  "expires_in": 3269,
  "ext_expires_in": 0,
  "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQTZOVGFlN0NkV1c3UWZkQ0NDYy0tY0hGa18wZE50MVEtc2loVzRMd2RwQVZISGpnTVdQZ0tQeVJIaGlDbUN2NkdyMEpmYmRfY1RmMUFxU21TcFJkVXVydVJqX3Nqd0JoN211eHlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIiwia2lkIjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMWRiNDcvIiwiaWF0IjoxNDkzOTMwMzA1LCJuYmYiOjE0OTM5MzAzMDUsImV4cCI6MTQ5MzkzMzg3NSwiYWNyIjoiMCIsImFpbyI6IkFTUUEyLzhEQUFBQU9KYnFFWlRNTnEyZFcxYXpKN1RZMDlYeDdOT29EMkJEUlRWMXJ3b2ZRc1k9IiwiYW1yIjpbInB3ZCJdLCJhcHBfZGlzcGxheW5hbWUiOiJUb2RvRG90bmV0T2JvIiwiYXBwaWQiOiIyODQ2ZjcxYi1hN2E0LTQ5ODctYmFiMy03NjAwMzViMmYzODkiLCJhcHBpZGFjciI6IjEiLCJmYW1pbHlfbmFtZSI6IkNhbnVtYWxsYSIsImdpdmVuX25hbWUiOiJOYXZ5YSIsImlwYWRkciI6IjE2Ny4yMjAuMC4xOTkiLCJuYW1lIjoiTmF2eWEgQ2FudW1hbGxhIiwib2lkIjoiZDVlOTc5YzctM2QyZC00MmFmLThmMzAtNzI3ZGQ0YzJkMzgzIiwib25wcmVtX3NpZCI6IlMtMS01LTIxLTIxMjc1MjExODQtMTYwNDAxMjkyMC0xODg3OTI3NTI3LTI2MTE4NDg0IiwicGxhdGYiOiIxNCIsInB1aWQiOiIxMDAzM0ZGRkEwNkQxN0M5Iiwic2NwIjoiVXNlci5SZWFkIiwic3ViIjoibWtMMHBiLXlpMXQ1ckRGd2JTZ1JvTWxrZE52b3UzSjNWNm84UFE3alVCRSIsInRpZCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsInVuaXF1ZV9uYW1lIjoibmFjYW51bWFAbWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hY2FudW1hQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJWR1ItdmtEZlBFQ2M1dWFDaENRSkFBIiwidmVyIjoiMS4wIn0.cubh1L2VtruiiwF8ut1m9uNBmnUJeYx4x0G30F7CqSpzHj1Sv5DCgNZXyUz3pEiz77G8IfOF0_U5A_02k-xzwdYvtJUYGH3bFISzdqymiEGmdfCIRKl9KMeoo2llGv0ScCniIhr2U1yxTIkIpp092xcdaDt-2_2q_ql1Ha_HtjvTV1f9XR3t7_Id9bR5BqwVX5zPO7JMYDVhUZRx08eqZcC-F3wi0xd_5ND_mavMuxe2wrpF-EZviO3yg0QVRr59tE3AoWl8lSGpVc97vvRCnp4WVRk26jJhYXFPsdk4yWqOKZqzr3IFGyD08WizD_vPSrXcCPbZP3XWaoTUKZSNJg",
  "refresh_token": "OAQABAAAAAABnfiG-mA6NTae7CdWW7QfdAALzDWjw6qSn4GUDfxWzJDZ6lk9qRw4An{a lot of characters here}"
}

Het bovenstaande toegangstoken is een v1.0-opgemaakt token voor Microsoft Graph. Dit komt doordat de tokenindeling is gebaseerd op de resource die wordt geopend en niet is gerelateerd aan de eindpunten die worden gebruikt om deze aan te vragen. Microsoft Graph is ingesteld om v1.0-tokens te accepteren, zodat het Microsoft Identity Platform v1.0-toegangstokens produceert wanneer een client tokens aanvraagt voor Microsoft Graph. Andere apps kunnen erop wijzen dat ze v2.0-format tokens, v1.0-format tokens of zelfs eigen of versleutelde tokenindelingen willen. Zowel de v1.0- als v2.0-eindpunten kunnen beide indelingen van het token verzenden. Op deze manier kan de resource altijd de juiste indeling van het token krijgen, ongeacht hoe of waar het token is aangevraagd door de client.

Waarschuwing

Probeer geen tokens te valideren of te lezen voor een API die u niet bezit, inclusief de tokens in dit voorbeeld, in uw code. Tokens voor Microsoft-services kunnen gebruikmaken van een speciale indeling die niet als JWT wordt gevalideerd, en kan ook worden versleuteld voor gebruikers van consumenten (Microsoft-account). Hoewel het lezen van tokens een handig hulpprogramma voor foutopsporing en leren is, neemt u hier geen afhankelijkheden van in uw code of gaat u ervan uit dat u specifieke informatie over tokens gebruikt die niet voor een API die u beheert.

Voorbeeld van foutreactie

Er wordt een foutreactie geretourneerd door het tokeneindpunt bij het verkrijgen van een toegangstoken voor de downstream-API, als de downstream-API een beleid voor voorwaardelijke toegang (zoals meervoudige verificatie) heeft ingesteld. De service in de middelste laag moet deze fout weergeven aan de clienttoepassing, zodat de clienttoepassing de gebruikersinteractie kan bieden om te voldoen aan het beleid voor voorwaardelijke toegang.

{
    "error":"interaction_required",
    "error_description":"AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multifactor authentication to access 'bf8d80f9-9098-4972-b203-500f535113b1'.\r\nTrace ID: b72a68c3-0926-4b8e-bc35-3150069c2800\r\nCorrelation ID: 73d656cf-54b1-4eb2-b429-26d8165a52d7\r\nTimestamp: 2017-05-01 22:43:20Z",
    "error_codes":[50079],
    "timestamp":"2017-05-01 22:43:20Z",
    "trace_id":"b72a68c3-0926-4b8e-bc35-3150069c2800",
    "correlation_id":"73d656cf-54b1-4eb2-b429-26d8165a52d7",
    "claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"9ab03e19-ed42-4168-b6b7-7001fb3e933a\"]}}}"
}

Het toegangstoken gebruiken om toegang te krijgen tot de beveiligde resource

De service in de middelste laag kan nu het token gebruiken dat hierboven is verkregen om geverifieerde aanvragen naar de downstream-web-API te maken door het token in de Authorization header in te stellen.

Voorbeeld

GET /v1.0/me HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer eyJ0eXAiO ... 0X2tnSQLEANnSPHY0gKcgw

SAML-asserties verkregen met een OAuth2.0 OBO-stroom

Sommige op OAuth gebaseerde webservices moeten toegang hebben tot andere webservice-API's die SAML-asserties accepteren in niet-interactieve stromen. Azure Active Directory kan een SAML-assertie bieden als reactie op een on-Behalf-Of-stroom die gebruikmaakt van een op SAML gebaseerde webservice als doelresource.

Dit is een niet-standaardextensie voor de OAuth 2.0 On-Behalf-Of-stroom waarmee een op OAuth2 gebaseerde toepassing toegang heeft tot eindpunten van de webservice-API die SAML-tokens gebruiken.

Tip

Wanneer u een met SAML beveiligde webservice aanroept vanuit een front-endwebtoepassing, kunt u de API aanroepen en een normale interactieve verificatiestroom initiëren met de bestaande sessie van de gebruiker. U hoeft alleen een OBO-stroom te gebruiken wanneer voor een service-naar-service-aanroep een SAML-token is vereist om gebruikerscontext te bieden.

Een SAML-token verkrijgen met behulp van een OBO-aanvraag met een gedeeld geheim

Een service-naar-serviceaanvraag voor een SAML-assertie bevat de volgende parameters:

Parameter Type Description
grant_type vereist Het type tokenaanvraag. Voor een aanvraag die gebruikmaakt van een JWT, moet de waarde zijn urn:ietf:params:oauth:grant-type:jwt-bearer.
Bewering vereist De waarde van het toegangstoken dat in de aanvraag wordt gebruikt.
client_id vereist De app-id die is toegewezen aan de aanroepende service tijdens de registratie met Azure AD. Als u de app-id in Azure Portal wilt vinden, selecteert u Active Directory, kiest u de map en selecteert u vervolgens de naam van de toepassing.
client_secret vereist De sleutel die is geregistreerd voor de aanroepende service in Azure AD. Deze waarde moet op het moment van registratie zijn genoteerd. Het basisverificatiepatroon van in plaats daarvan referenties in de autorisatieheader op te geven, wordt ook ondersteund per RFC 6749 .
scope vereist Een door spaties gescheiden lijst met bereiken voor de tokenaanvraag. Zie bereiken voor meer informatie. SAML zelf heeft geen concept van bereiken, maar hier wordt het gebruikt om de doel-SAML-toepassing te identificeren waarvoor u een token wilt ontvangen. Voor deze OBO-stroom moet de bereikwaarde altijd de SAML-entiteits-id zijn waaraan /.default is toegevoegd. Als de entiteits-id van de SAML-toepassing bijvoorbeeld is https://testapp.contoso.com, moet het aangevraagde bereik zijn https://testapp.contoso.com/.default. Als de entiteits-id niet begint met een URI-schema, zoals https:, wordt de entiteits-id voorafgegaan door spn:Azure AD. In dat geval moet u het bereik spn:<EntityID>/.defaultaanvragen, bijvoorbeeld spn:testapp/.default in het geval dat de entiteits-id is testapp. Houd er rekening mee dat de bereikwaarde die u hier aanvraagt, het resulterende Audience element in het SAML-token bepaalt. Dit kan belangrijk zijn voor de SAML-toepassing die het token ontvangt.
requested_token_use vereist Hiermee geeft u op hoe de aanvraag moet worden verwerkt. In de on-Behalf-Of-stroom moet de waarde zijn on_behalf_of.
requested_token_type vereist Hiermee geeft u het type token aangevraagd. De waarde kan zijn urn:ietf:params:oauth:token-type:saml2 of urn:ietf:params:oauth:token-type:saml1 afhankelijk van de vereisten van de geopende resource.

Het antwoord bevat een SAML-token dat is gecodeerd in UTF8 en Base64url.

  • SubjectConfirmationData voor een SAML-assertie die afkomstig is van een OBO-aanroep: Als voor de doeltoepassing een ontvangerwaarde in SubjectConfirmationData is vereist, moet de waarde een antwoord-URL zonder jokerteken zijn in de configuratie van de resourcetoepassing.
  • Het knooppunt SubjectConfirmationData: het knooppunt kan geen InResponseTo-kenmerk bevatten, omdat het geen deel uitmaakt van een SAML-antwoord. De toepassing die het SAML-token ontvangt, moet de SAML-assertie kunnen accepteren zonder een InResponseTo-kenmerk .
  • API-machtigingen: u moet de benodigde API-machtigingen toevoegen aan de toepassing in de middelste laag om toegang tot de SAML-toepassing toe te staan, zodat er een token kan worden aangevraagd voor het /.default bereik van de SAML-toepassing.
  • Toestemming: toestemming moet zijn verleend voor het ontvangen van een SAML-token met gebruikersgegevens in een OAuth-stroom. Zie Het verkrijgen van toestemming voor de toepassing in de middelste laag hieronder voor meer informatie.

Antwoord met SAML-assertie

Parameter Beschrijving
token_type Geeft de waarde van het tokentype aan. Het enige type dat Door Azure AD wordt ondersteund, is Bearer. Zie OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) voor meer informatie over bearer-tokens.
scope Het toegangsbereik dat in het token wordt verleend.
expires_in De tijdsduur van het toegangstoken is geldig (in seconden).
expires_on Het tijdstip waarop het toegangstoken verloopt. De datum wordt weergegeven als het aantal seconden van 1970-01-01T0:0:0Z UTC tot de verlooptijd. Deze waarde wordt gebruikt om de levensduur van tokens in de cache te bepalen.
resource De app-id-URI van de ontvangende service (beveiligde resource).
access_token De parameter die de SAML-assertie retourneert.
refresh_token Het vernieuwingstoken. De aanroepende service kan dit token gebruiken om een ander toegangstoken aan te vragen nadat de huidige SAML-assertie is verlopen.
  • token_type: Bearer
  • expires_in: 3296
  • ext_expires_in: 0
  • expires_on: 1529627844
  • Resource: https://api.contoso.com
  • access_token: <SAML-assertie>
  • issued_token_type: urn:ietf:params:oauth:token-type:saml2
  • refresh_token: <token vernieuwen>

Afhankelijk van de architectuur of het gebruik van uw toepassing, kunt u verschillende strategieën overwegen om ervoor te zorgen dat de OBO-stroom succesvol is. In alle gevallen is het uiteindelijke doel om ervoor te zorgen dat de juiste toestemming wordt gegeven, zodat de client-app de middelste laag-app kan aanroepen en de middelste laag-app gemachtigd is om de back-endresource aan te roepen.

Notitie

Voorheen biedt het Microsoft-accountsysteem (persoonlijke accounts) geen ondersteuning voor het veld 'bekende clienttoepassingen', en kon het geen gecombineerde toestemming tonen. Dit is toegevoegd en alle apps in het Microsoft Identity Platform kunnen de bekende clienttoepassingsbenadering gebruiken om toestemming te krijgen voor OBO-aanroepen.

De toepassing met de middelste laag voegt de client toe aan de lijst met bekende clienttoepassingen (knownClientApplications) in het manifest. Als een toestemmingsprompt wordt geactiveerd door de client, is de toestemmingsstroom zowel voor zichzelf als de middelste laagtoepassing. Op het Microsoft Identity Platform wordt dit gedaan met behulp van het .default bereik. Wanneer u een toestemmingsscherm activeert met behulp van bekende clienttoepassingen en .default, worden in het toestemmingsscherm machtigingen weergegeven voor zowel de client als de API voor de middelste laag en wordt ook gevraagd welke machtigingen zijn vereist door de API voor de middelste laag. De gebruiker geeft toestemming voor beide toepassingen en vervolgens werkt de OBO-stroom.

De resourceservice (API) die in de aanvraag is geïdentificeerd, moet de API zijn waarvoor de clienttoepassing een toegangstoken aanvraagt als gevolg van de aanmelding van de gebruiker. Bijvoorbeeld scope=openid https://middle-tier-api.example.com/.default (als u een toegangstoken wilt aanvragen voor de API voor de middelste laag), of scope=openid offline_access .default (wanneer een resource niet wordt geïdentificeerd, wordt dit standaard ingesteld op Microsoft Graph).

Ongeacht welke API wordt geïdentificeerd in de autorisatieaanvraag, is de toestemmingsprompt een gecombineerde toestemmingsprompt, inclusief alle vereiste machtigingen die zijn geconfigureerd voor de client-app, evenals alle vereiste machtigingen die zijn geconfigureerd voor elke API voor de middelste laag die wordt vermeld in de lijst met vereiste machtigingen van de client en die de client hebben geïdentificeerd als een bekende clienttoepassing.

Vooraf geautoriseerde toepassingen

Resources kunnen aangeven dat een bepaalde toepassing altijd gemachtigd is om bepaalde bereiken te ontvangen. Dit is voornamelijk handig om verbindingen tussen een front-endclient en een back-endresource naadlooser te maken. Een resource kan meerdere vooraf geautoriseerde toepassingen (preAuthorizedApplications) in het manifest declareren. Elke dergelijke toepassing kan deze machtigingen aanvragen in een OBO-stroom en deze ontvangen zonder dat de gebruiker toestemming geeft.

Een tenantbeheerder kan garanderen dat toepassingen gemachtigd zijn om hun vereiste API's aan te roepen door beheerderstoestemming te geven voor de middelste laag-toepassing. Om dit te doen, kan de beheerder de toepassing in de middelste laag vinden in hun tenant, de pagina met vereiste machtigingen openen en ervoor kiezen om de app toestemming te geven. Zie de documentatie over toestemming en machtigingen voor meer informatie over beheerderstoestemming.

Gebruik van één toepassing

In sommige scenario's hebt u mogelijk slechts één koppeling van de middelste laag en front-endclient. In dit scenario is het mogelijk gemakkelijker om deze één toepassing te maken, waardoor de noodzaak voor een toepassing in de middelste laag helemaal wordt ontkend. Voor verificatie tussen de front-end en de web-API kunt u cookies, een id_token of een toegangstoken gebruiken dat is aangevraagd voor de toepassing zelf. Vraag vervolgens toestemming van deze enkele toepassing aan de back-endresource.

Volgende stappen

Meer informatie over het OAuth 2.0-protocol en een andere manier om service-naar-serviceverificatie uit te voeren met behulp van clientreferenties.