Woordenlijst: Microsoft Identity Platform

Artikel
03/20/2024

U ziet deze voorwaarden wanneer u onze documentatie, het Microsoft Entra-beheercentrum, onze verificatiebibliotheken en de Microsoft Graph API gebruikt. Sommige begrippen zijn specifiek voor Microsoft, terwijl andere gerelateerd zijn aan protocollen zoals OAuth of andere technologieën die u gebruikt met het Microsoft Identity Platform.

Toegangstoken

Een type beveiligingstoken dat is uitgegeven door een autorisatieserver en wordt gebruikt door een clienttoepassing voor toegang tot een beveiligde bronserver. Het token heeft de vorm van een JSON Web Token (JWT) en belichaamt de autorisatie die door de resource-eigenaar aan de client wordt verleend voor een aangevraagd toegangsniveau. Het token bevat alle toepasselijke claims over het onderwerp, waardoor de clienttoepassing deze kan gebruiken als een vorm van referenties bij het openen van een bepaalde resource. Dit elimineert ook de noodzaak voor de resource-eigenaar om referenties beschikbaar te maken voor de client.

Toegangstokens zijn slechts korte tijd geldig en kunnen niet worden ingetrokken. Een autorisatieserver kan ook een vernieuwingstoken uitgeven wanneer het toegangstoken wordt uitgegeven. Vernieuwingstokens worden doorgaans alleen verstrekt aan vertrouwelijke clienttoepassingen.

Toegangstokens worden soms 'User+App' of 'App-Only' genoemd, afhankelijk van de referenties die worden weergegeven. Bijvoorbeeld wanneer een clienttoepassing gebruikmaakt van het volgende:

Autorisatietoekenning 'Autorisatiecode', de eindgebruiker verifieert zich eerst als resource-eigenaar en delegeert autorisatie aan de client om toegang te krijgen tot de resource. De client wordt later geverifieerd bij het verkrijgen van het toegangstoken. Het token kan soms specifieker worden aangeduid als een token 'User+App', omdat het zowel de gebruiker vertegenwoordigt die de clienttoepassing heeft geautoriseerd als de toepassing.
Autorisatietoekenning 'Clientreferenties', de client biedt de enige verificatie, die werkt zonder verificatie/autorisatie van de resource-eigenaar, zodat het token soms kan worden aangeduid als een token 'App-Only'.

Zie de naslaginformatie over toegangstokens voor meer informatie.

Acteur

Een andere term voor de clienttoepassing. De actor is de partij die handelt namens een onderwerp (resource-eigenaar).

Client-id van toepassing

De toepassings-id of client-id is een waarde die het Microsoft Identity Platform toewijst aan uw toepassing wanneer u deze registreert in Microsoft Entra-id. De toepassings-id is een GUID-waarde die de toepassing en de configuratie ervan uniek identificeert binnen het identiteitsplatform. U voegt de app-id toe aan de code van uw toepassing en verificatiebibliotheken nemen de waarde op in hun aanvragen voor het identiteitsplatform tijdens de toepassingsruntime. De toepassings-id (client) is geen geheim. Gebruik deze niet als wachtwoord of andere referenties.

Manifest van de toepassing

Een toepassingsmanifest is een functie die een JSON-weergave produceert van de identiteitsconfiguratie van de toepassing, die wordt gebruikt als mechanisme voor het bijwerken van de bijbehorende toepassings - en ServicePrincipal-entiteiten . Zie Het Manifest van de Microsoft Entra-toepassing voor meer informatie.

Toepassingsobject

Wanneer u een toepassing registreert/bijwerkt, worden zowel een toepassingsobject als een bijbehorend service-principalobject voor die tenant gemaakt/bijgewerkt. Het toepassingsobject definieert de identiteitsconfiguratie van de toepassing op globaal niveau (voor alle tenants waar het toegang heeft), waarbij een sjabloon wordt opgegeven waaruit het/de bijbehorende service-principalobject(en) worden afgeleid voor lokaal gebruik tijdens runtime (in een specifieke tenant).

Zie Toepassing en service-principalobjecten voor meer informatie.

Toepassingsregistratie

Als u wilt dat een toepassing kan worden geïntegreerd met functies voor identiteits- en toegangsbeheer en delegeren aan Microsoft Entra-id, moet deze zijn geregistreerd bij een Microsoft Entra-tenant. Wanneer u uw toepassing registreert bij Microsoft Entra ID, geeft u een identiteitsconfiguratie voor uw toepassing op, zodat deze kan worden geïntegreerd met Microsoft Entra ID en functies zoals:

Robuust beheer van eenmalige aanmelding met behulp van Microsoft Entra Identity Management en de implementatie van het OpenID Connect-protocol
Brokered-toegang tot beveiligde resources door clienttoepassingen, via OAuth 2.0-autorisatieserver
Toestemmingsframework voor het beheren van clienttoegang tot beveiligde resources, op basis van autorisatie van resource-eigenaar.

Zie Toepassingen integreren met Microsoft Entra ID voor meer informatie.

Verificatie

Hierbij wordt een partij gevraagd om legitieme referenties. Op basis hiervan kan een beveiligingsprincipal worden gemaakt voor identiteits- en toegangsbeheer. Tijdens een OAuth 2.0-autorisatietoekenning wordt bijvoorbeeld de rol van resource-eigenaar of clienttoepassing ingevuld door de verifiërende partij, afhankelijk van de gebruikte toekenning.

Autorisatie

Hierbij krijgt een geverifieerde beveiligingsprincipal toestemming om iets te doen. Er zijn twee primaire use cases in het Microsoft Entra-programmeermodel:

Tijdens een OAuth 2.0-stroom voor autorisatie: wanneer de resource-eigenaar autorisatie verleent aan de clienttoepassing, zodat de client toegang verkrijgt tot de resources van de resource-eigenaar.
Wanneer de client resources opent: zoals geïmplementeerd door de resourceserver, met gebruik van de claimwaarden in het toegangstoken, om toegangsbeheerbeslissingen te nemen op basis van die waarden.

Autorisatiecode

Een waarde met een korte levensduur die door het autorisatie-eindpunt wordt verstrekt aan een clienttoepassing tijdens de OAuth 2.0-autorisatiecodetoekenningsstroom, een van de vier OAuth 2.0-autorisatietoekenningen. De autorisatiecode wordt ook wel verificatiecode genoemd en wordt geretourneerd naar de clienttoepassing als reactie op de verificatie van een resource-eigenaar. De verificatiecode geeft aan dat de resource-eigenaar autorisatie heeft gedelegeerd aan de clienttoepassing om toegang te krijgen tot hun resources. Als onderdeel van de stroom wordt de verificatiecode later ingewisseld voor een toegangstoken.

Autorisatie-eindpunt

Een van de eindpunten die zijn geïmplementeerd door de autorisatieserver, die worden gebruikt om te communiceren met de resource-eigenaar om een autorisatietoekenning te verlenen tijdens een OAuth 2.0-autorisatietoekenningsstroom. Afhankelijk van de stroom voor autorisatietoekenning die wordt gebruikt, kan de opgegeven werkelijke toekenning variëren, inclusief een autorisatiecode of een beveiligingstoken.

Zie de secties autorisatietoekenningstypen en autorisatie-eindpunten van de OAuth 2.0-specificatie en de OpenIDConnect-specificatie voor meer informatie.

Autorisatietoekenning

Een referentie die de autorisatie van de resource-eigenaar vertegenwoordigt voor toegang tot de beveiligde resources, verleend aan een clienttoepassing. Een clienttoepassing kan een van de vier toekenningstypen gebruiken die zijn gedefinieerd door het OAuth 2.0-autorisatieframework om een toekenning te verkrijgen, afhankelijk van het type/de vereisten van de client: 'autorisatiecodetoekenning', 'clientreferentiestoekenning', 'impliciete toekenning' en 'toekenning wachtwoordreferenties voor resource-eigenaar'. De referentie die naar de client wordt geretourneerd, is een toegangstoken of een autorisatiecode (later uitgewisseld voor een toegangstoken), afhankelijk van het type autorisatietoekenning dat wordt gebruikt.

De referenties voor het wachtwoord van de resource-eigenaar mogen niet worden gebruikt , behalve in scenario's waarin andere stromen niet kunnen worden gebruikt. Als u een beveiligd-WACHTWOORDVERIFICATIE bouwt, gebruikt u de autorisatiecodestroom met PKCE in plaats van impliciete toekenning.

Autorisatieserver

Zoals gedefinieerd door het OAuth 2.0-autorisatieframework, is de server die verantwoordelijk is voor het uitgeven van toegangstokens aan de client nadat de resource-eigenaar is geverifieerd en de autorisatie heeft verkregen. Een clienttoepassing communiceert tijdens runtime met de autorisatieserver via de autorisatie- en token-eindpunten, in overeenstemming met de door OAuth 2.0 gedefinieerde autorisatietoekenningen.

In het geval van de integratie van de Microsoft Identity Platform-toepassing implementeert het Microsoft Identity Platform de rol autorisatieserver voor Microsoft Entra-toepassingen en Microsoft-service-API's, bijvoorbeeld Microsoft Graph-API's.

Claim

Claims zijn naam-/waardenparen in een beveiligingstoken die asserties van de ene entiteit aan een andere bieden. Deze entiteiten zijn doorgaans de clienttoepassing of een resource-eigenaar die asserties aan een resourceserver verstrekt. Claims geven feiten door over het tokenonderwerp, zoals de id van de beveiligingsprincipal die is geverifieerd door de autorisatieserver. De claims die aanwezig zijn in een token kunnen variëren en zijn afhankelijk van verschillende factoren, zoals het type token, het type referentie dat wordt gebruikt voor het verifiëren van het onderwerp, de toepassingsconfiguratie en andere.

Zie de Naslaginformatie over Microsoft Identity Platform-token voor meer informatie.

Clienttoepassing

Ook wel bekend als de 'actor'. Zoals gedefinieerd door het OAuth 2.0-autorisatieframework, een toepassing die beveiligde resourceaanvragen namens de resource-eigenaar doet. Ze ontvangen machtigingen van de resource-eigenaar in de vorm van bereiken. De term 'client' impliceert geen specifieke hardware-implementatiekenmerken (bijvoorbeeld of de toepassing wordt uitgevoerd op een server, een desktop of andere apparaten).

Een clienttoepassing vraagt autorisatie aan bij een resource-eigenaar om deel te nemen aan een OAuth 2.0-autorisatietoekenningsstroom en heeft namens de resource-eigenaar toegang tot API's/gegevens. Het OAuth 2.0-autorisatieframework definieert twee typen clients, 'vertrouwelijk' en 'openbaar', op basis van de mogelijkheid van de client om de vertrouwelijkheid van de referenties te behouden. Toepassingen kunnen een webclient (vertrouwelijk) implementeren die wordt uitgevoerd op een webserver, een systeemeigen client (openbaar) die op een apparaat is geïnstalleerd of een op gebruikersagent gebaseerde client (openbaar) die wordt uitgevoerd in de browser van een apparaat.

Het proces van een resource-eigenaar die autorisatie verleent aan een clienttoepassing, voor toegang tot beveiligde resources onder specifieke machtigingen namens de resource-eigenaar. Afhankelijk van de machtigingen die door de client zijn aangevraagd, wordt een beheerder of gebruiker gevraagd om toestemming om respectievelijk toegang tot hun organisatie/afzonderlijke gegevens toe te staan. In een scenario met meerdere tenants wordt de service-principal van de toepassing ook vastgelegd in de tenant van de toestemmingsgebruiker.

Zie toestemmingsframework voor meer informatie.

Id-token

Een OpenID Connect-beveiligingstoken dat wordt geleverd door het autorisatie-eindpunt van een autorisatieserver, dat claims bevat die betrekking hebben op de verificatie van de eigenaar van een eindgebruikerresource. Net als een toegangstoken worden id-tokens ook weergegeven als een digitaal ondertekend JSON Web Token (JWT). In tegenstelling tot een toegangstoken worden de claims van een id-token echter niet gebruikt voor doeleinden met betrekking tot toegang tot resources en specifiek toegangsbeheer.

Zie de Naslaginformatie over id-token voor meer informatie.

Beheerde identiteiten

Elimineren de noodzaak voor ontwikkelaars om referenties te beheren. Beheerde identiteiten bieden een identiteit die toepassingen kunnen gebruiken bij het maken van verbinding met resources die ondersteuning bieden voor Microsoft Entra-verificatie. Toepassingen kunnen de beheerde identiteit gebruiken om Microsoft Identity Platform-tokens te verkrijgen. Een toepassing kan bijvoorbeeld een beheerde identiteit gebruiken om toegang te krijgen tot resources zoals Azure Key Vault waar ontwikkelaars referenties op een veilige manier kunnen opslaan of toegang hebben tot opslagaccounts. Zie Overzicht van beheerde identiteiten voor meer informatie.

Microsoft Identity Platform

Het Microsoft Identity Platform is een evolutie van de Microsoft Entra-identiteitsservice en het ontwikkelaarsplatform. Met het Microsoft Identity Platform kunnen ontwikkelaars toepassingen maken waarbij gebruikers zich met alle Microsoft-identiteiten kunnen aanmelden en waarmee tokens worden opgehaald voor het aanroepen van Microsoft Graph, andere Microsoft-API's of API's die door ontwikkelaars zijn gemaakt. Het platform biedt uitgebreide functionaliteit en bevat een verificatieservice, bibliotheken, mogelijkheden voor toepassingsregistratie en -configuratie, volledige ontwikkelaarsdocumentatie, codevoorbeelden en andere inhoud voor ontwikkelaars. Het Microsoft Identity Platform biedt ondersteuning voor standaardprotocollen als OAuth 2.0 en OpenID Connect.

Toepassing met meerdere tenants

Een toepassingsklasse waarmee gebruikers zich kunnen aanmelden en toestemming geven die zijn ingericht in een Microsoft Entra-tenant , met inbegrip van andere tenants dan de tenant waarin de client is geregistreerd. Systeemeigen clienttoepassingen vallen standaard onder meerdere tenants, terwijl webclient- en webresource-/API-toepassingen de mogelijkheid hebben om te kiezen tussen één of meerdere tenants. Een webtoepassing die is geregistreerd als één tenant, staat daarentegen alleen aanmeldingen toe van gebruikersaccounts die zijn ingericht in dezelfde tenant als de tenant waarop de toepassing is geregistreerd.

Zie Hoe u zich aanmeldt bij een Microsoft Entra-gebruiker met behulp van het toepassingspatroon voor meerdere tenants voor meer informatie.

Systeemeigen client

Een type clienttoepassing dat systeemeigen op een apparaat is geïnstalleerd. Omdat alle code op een apparaat wordt uitgevoerd, wordt deze beschouwd als een 'openbare' client vanwege het onvermogen om referenties privé/vertrouwelijk op te slaan. Zie OAuth 2.0-clienttypen en -profielen voor meer informatie.

Machtigingen

Een clienttoepassing krijgt toegang tot een resourceserver door machtigingsaanvragen te declareren. Er zijn twee typen beschikbaar:

'Gedelegeerde' machtigingen, die toegang op basis van een bereik opgeven met behulp van gedelegeerde autorisatie van de aangemelde resource-eigenaar, worden tijdens runtime gepresenteerd aan de resource als 'scp'-claims in het toegangstoken van de client. Deze geven de machtiging aan die door het onderwerp aan de actor is verleend.
'Toepassingsmachtigingen', die toegang op basis van een rol opgeven met behulp van de referenties/identiteit van de clienttoepassing, worden tijdens runtime gepresenteerd aan de resource als 'rollen'-claims in het toegangstoken van de client. Deze geven machtigingen aan die door de tenant aan het onderwerp zijn toegekend.

Ze komen ook voor tijdens het toestemmingsproces, waardoor de beheerder of resource-eigenaar de mogelijkheid heeft om de client toegang tot resources in de tenant toe te kennen of te weigeren.

Machtigingsaanvragen worden geconfigureerd op de pagina API-machtigingen voor een toepassing door de gewenste 'Gedelegeerde machtigingen' en 'Toepassingsmachtigingen' te selecteren (de laatste vereist lidmaatschap van de rol Globale beheerder). Omdat een openbare client referenties niet veilig kan onderhouden, kan deze alleen gedelegeerde machtigingen aanvragen, terwijl een vertrouwelijke client de mogelijkheid heeft om zowel gedelegeerde als toepassingsmachtigingen aan te vragen. Het toepassingsobject van de client slaat de gedeclareerde machtigingen op in de requiredResourceAccess-eigenschap.

Token vernieuwen

Een type beveiligingstoken dat is uitgegeven door een autorisatieserver. Voordat een toegangstoken verloopt, bevat een clienttoepassing het bijbehorende vernieuwingstoken wanneer er een nieuw toegangstoken van de autorisatieserver wordt aangevraagd. Vernieuwingstokens worden doorgaans opgemaakt als een JSON Web Token (JWT).

In tegenstelling tot toegangstokens kunnen vernieuwingstokens worden ingetrokken. Een autorisatieserver weigert een aanvraag van een clienttoepassing die een vernieuwingstoken bevat dat is ingetrokken. Wanneer de autorisatieserver een aanvraag met een ingetrokken vernieuwingstoken weigert, verliest de clienttoepassing de machtiging voor toegang tot de resourceserver namens de resource-eigenaar.

Zie de vernieuwingstokens voor meer informatie.

Resource-eigenaar

Zoals gedefinieerd door het OAuth 2.0-autorisatieframework, is dit een entiteit die toegang tot een beveiligde resource kan toekennen. Wanneer de resource-eigenaar een persoon is, wordt deze een eindgebruiker genoemd. Wanneer een clienttoepassing bijvoorbeeld toegang wil krijgen tot het postvak van een gebruiker via de Microsoft Graph API, is hiervoor toestemming vereist van de resource-eigenaar van het postvak. De 'resource-eigenaar' wordt soms ook wel het onderwerp genoemd.

Elk beveiligingstoken vertegenwoordigt een resource-eigenaar. De resource-eigenaar is wat de onderwerpclaim, object-id-claim en persoonlijke gegevens in het token vertegenwoordigen. Resource-eigenaren zijn de partij die gedelegeerde machtigingen toekent aan een clienttoepassing, in de vorm van bereiken. Resource-eigenaren zijn ook de ontvangers van rollen die uitgebreide machtigingen binnen een tenant of in een toepassing aangeven.

Resourceserver

Zoals gedefinieerd door het OAuth 2.0-autorisatieframework, een server die beveiligde resources host, in staat is om beveiligde resourceaanvragen van clienttoepassingen die een toegangstoken presenteren te accepteren en erop te reageren. Dit wordt ook wel een beveiligde resourceserver of resourcetoepassing genoemd.

Een resourceserver maakt API's beschikbaar en dwingt toegang tot de beveiligde resources af via bereiken en rollen, met behulp van het OAuth 2.0-autorisatieframework. Voorbeelden hiervan zijn de Microsoft Graph API, die toegang biedt tot Microsoft Entra-tenantgegevens en de Microsoft 365-API's die toegang bieden tot gegevens zoals e-mail en agenda.

Net als bij een clienttoepassing wordt de identiteitsconfiguratie van de resourcetoepassing tot stand gebracht via registratie in een Microsoft Entra-tenant, die zowel het toepassingsobject als het service-principal-object levert. Sommige door Microsoft geleverde API's, zoals de Microsoft Graph API, hebben vooraf geregistreerde service-principals beschikbaar gesteld in alle tenants tijdens het inrichten.

Rollen

Net als bereiken bieden app-rollen een manier voor een resourceserver om de toegang tot de beveiligde resources te beheren. In tegenstelling tot bereiken vertegenwoordigen rollen bevoegdheden die het onderwerp buiten de basislijn heeft gekregen. Daarom is het lezen van uw eigen e-mail een bereik, terwijl het zijn van een e-mailbeheerder die de e-mail van iedereen kan lezen een rol is.

App-rollen kunnen twee toewijzingstypen ondersteunen: 'gebruikerstoewijzing' implementeert op rollen gebaseerd toegangsbeheer voor gebruikers/groepen waarvoor toegang tot de resource is vereist, terwijl 'toepassingstoewijzing' hetzelfde implementeert voor clienttoepassingen waarvoor toegang is vereist. Een app-rol kan worden gedefinieerd als door de gebruiker toewijsbaar, door de app toewijsbaar of beide.

Rollen zijn door resources gedefinieerde tekenreeksen (bijvoorbeeld 'Onkostenkeuriger', 'Alleen-lezen', 'Directory.ReadWrite.All'), beheerd via het toepassingsmanifest van de resource en opgeslagen in de eigenschap appRoles van de resource. Gebruikers kunnen worden toegewezen aan 'door de gebruiker' toewijsbare rollen en machtigingen voor clienttoepassingen kunnen worden geconfigureerd om toewijsbare rollen voor toepassingen aan te vragen.

Zie Graph API Machtigingsbereiken voor een gedetailleerde bespreking van de toepassingsrollen die worden weergegeven door de Microsoft Graph API. Zie Azure-roltoewijzingen toevoegen of verwijderen voor een stapsgewijze implementatie.

Bereiken

Net als rollen bieden bereiken een manier voor een resourceserver om de toegang tot de beveiligde resources te beheren. Bereiken worden gebruikt om toegangsbeheer op basis van bereik te implementeren voor een clienttoepassing die door de eigenaar gedelegeerde toegang tot de resource heeft gekregen.

Bereiken zijn door de resource gedefinieerde tekenreeksen (bijvoorbeeld Mail.Read, Directory.ReadWrite.All), beheerd via het toepassingsmanifest van de resource en opgeslagen in de eigenschap oauth2Permissions van de resource. Gedelegeerde machtigingen voor clienttoepassingen kunnen worden geconfigureerd voor toegang tot een bereik.

Een best practice voor naamconventie is het gebruik van de indeling 'resource.operation.constraint'. Zie Graph API Machtigingsbereiken voor een gedetailleerde bespreking van de bereiken die worden weergegeven door de Microsoft Graph API. Zie de naslaginformatie over Microsoft 365-API-machtigingen voor bereiken die worden weergegeven door Microsoft 365-services.

Beveiligingstoken

Een ondertekend document met claims, zoals een OAuth 2.0-token of SAML 2.0-assertie. Voor een OAuth 2.0-autorisatietoekenning, zijn een toegangstoken (OAuth2), vernieuwingstoken en een id-token typen beveiligingstokens, die allemaal worden geïmplementeerd als een JSON Web Token (JWT).

Service-principalobject

Wanneer u een toepassing registreert/bijwerkt, worden zowel een toepassingsobject als een bijbehorend service-principalobject voor die tenant gemaakt/bijgewerkt. Het toepassingsobject definieert de identiteitsconfiguratie van de toepassing op globaal niveau (voor alle tenants waar de gekoppelde toepassing toegang toegekend heeft gekregen), en is de sjabloon waaruit het/de bijbehorende service-principalobject(en) worden afgeleid voor lokaal gebruik tijdens runtime (in een specifieke tenant).

Zie Toepassing en service-principalobjecten voor meer informatie.

Het proces van een clienttoepassing voor het initiëren van verificatie door eindgebruikers en het vastleggen van de gerelateerde status voor het aanvragen van een beveiligingstoken en het bereik bepalen van de toepassingssessie tot die status. Status kan artefacten bevatten, zoals gebruikersprofielgegevens en informatie die is afgeleid van tokenclaims.

De aanmeldingsfunctie van een toepassing wordt doorgaans gebruikt om eenmalige aanmelding (SSO) te implementeren. Het kan ook worden voorafgegaan door een 'aanmeldings'-functie, als het invoerpunt voor een eindgebruiker om toegang te krijgen tot een toepassing (bij de eerste aanmelding). De aanmeldingsfunctie wordt gebruikt om aanvullende statussen te verzamelen en te behouden die specifiek zijn voor de gebruiker, en vereist mogelijk gebruikerstoestemming.

Afmelden

Het proces van het intrekken van verificatie voor een eindgebruiker, waarbij de gebruikersstatus die is gekoppeld aan de clienttoepassingssessie wordt losgekoppeld tijdens het aanmelden

Onderwerp

Ook wel de resource-eigenaar genoemd.

Tenant

Een exemplaar van een Microsoft Entra-directory wordt een Microsoft Entra-tenant genoemd. Deze biedt verschillende functies, waaronder:

een registerservice voor geïntegreerde toepassingen
verificatie van gebruikersaccounts en geregistreerde toepassingen
REST-eindpunten die nodig zijn voor de ondersteuning van verschillende protocollen, waaronder OAuth 2.0 en SAML, waaronder het autorisatie-eindpunt, het tokeneindpunt en het 'algemene' eindpunt dat wordt gebruikt door toepassingen met meerdere tenants.

Microsoft Entra-tenants worden tijdens de registratie gemaakt/gekoppeld aan Azure- en Microsoft 365-abonnementen, met identiteits- en toegangsbeheerfuncties voor het abonnement. Beheerders van Azure-abonnementen kunnen ook extra Microsoft Entra-tenants maken. Zie Hoe u een Microsoft Entra-tenant kunt krijgen voor meer informatie over de verschillende manieren waarop u toegang kunt krijgen tot een tenant. Zie Een Azure-abonnement koppelen aan of toevoegen aan uw Microsoft Entra-tenant voor meer informatie over de relatie tussen abonnementen en een Microsoft Entra-tenant en voor instructies over het koppelen of toevoegen van een abonnement aan een Microsoft Entra-tenant.

Tokeneindpunt

Een van de eindpunten die door de autorisatieserver zijn geïmplementeerd ter ondersteuning van OAuth 2.0-autorisatietoekenningen. Afhankelijk van de toekenning kan het worden gebruikt voor het verkrijgen van een toegangstoken (en gerelateerde vernieuwingstoken) aan een client of id-token wanneer deze wordt gebruikt met het OpenID Connect-protocol.

Client op basis van gebruikersagent

Een type clienttoepassing waarmee code van een webserver wordt gedownload en uitgevoerd binnen een gebruikersagent (bijvoorbeeld een webbrowser), zoals een toepassing met één pagina (SPA). Omdat alle code op een apparaat wordt uitgevoerd, wordt deze beschouwd als een 'openbare' client vanwege het onvermogen om referenties privé/vertrouwelijk op te slaan. Zie OAuth 2.0-clienttypen en -profielen voor meer informatie.

Principal van gebruiker

Net zoals een service-principalobject wordt gebruikt om een toepassingsexemplaar te vertegenwoordigen, is een object 'principal van gebruiker' een ander type beveiligingsprincipal, dat een gebruiker vertegenwoordigt. Het resourcetype Microsoft Graph User definieert het schema voor een gebruikersobject, inclusief eigenschappen die betrekking hebben op gebruikers, zoals voor- en achternaam, user principal name, directory role membership, enzovoort. Dit biedt de configuratie van de gebruikersidentiteit voor Microsoft Entra-id om tijdens runtime een gebruikers-principal tot stand te brengen. De principal van de gebruiker wordt gebruikt om een geverifieerde gebruiker te vertegenwoordigen voor eenmalige aanmelding, het vastleggen van toestemmingsdelegering , het nemen van beslissingen over toegangsbeheer, enzovoort.

Webclient

Een type clienttoepassing waarmee alle code op een webserver wordt uitgevoerd, die werkt als een vertrouwelijke client, omdat deze de referenties op de server veilig kan opslaan. Zie OAuth 2.0-clienttypen en -profielen voor meer informatie.

Workload-identiteit

Een identiteit die wordt gebruikt door een softwareworkload, zoals een toepassing, service, script of container voor verificatie en toegang tot andere services en resources. In Microsoft Entra ID zijn workloadidentiteiten apps, service-principals en beheerde identiteiten. Zie Overzicht van workload-identiteit voor meer informatie.

Workloadidentiteitsfederatie

Hiermee hebt u veilig toegang tot met Microsoft Entra beveiligde resources van externe apps en services zonder dat u geheimen hoeft te beheren (voor ondersteunde scenario's). Zie federatie van workloadidentiteit voor meer informatie.

Volgende stappen

Veel van de termen in deze woordenlijst zijn gerelateerd aan de OAuth 2.0- en OpenID Connect-protocollen. Hoewel u niet hoeft te weten hoe de protocollen 'op de kabel' werken om het identiteitsplatform te gebruiken, kunt u met behulp van enkele protocolbasisbeginselen eenvoudiger verificatie en autorisatie in uw apps bouwen en fouten opsporen in verificatie en autorisatie:

OAuth 2.0 en OpenID Connect (OIDC) op het Microsoft Identity Platform

Delen via