Wat is verificatie?What is authentication?

Waarschuwing

Deze inhoud is voor het oudere Azure AD v1.0-eindpunt.This content is for the older Azure AD v1.0 endpoint. Gebruik het Microsoft Identity Platform voor nieuwe projecten.Use the Microsoft identity platform for new projects.

Bij verificatie wordt een partij gevraagd om legitieme referenties. Op basis hiervan kan een beveiligingsprincipal worden gemaakt voor identiteits- en toegangsbeheer.Authentication is the act of challenging a party for legitimate credentials, providing the basis for creation of a security principal to be used for identity and access control. Eenvoudiger gezegd wordt bij dit proces bewezen dat u bent wie u zegt te zijn.In simpler terms, it's the process of proving you are who you say you are. Verificatie wordt soms afgekort tot 'AuthN'.Authentication is sometimes shortened to AuthN.

Bij autorisatie krijgt een geverifieerde beveiligingsprincipal toestemming om iets te doen.Authorization is the act of granting an authenticated security principal permission to do something. Er wordt aangegeven welke gegevens mogen worden gebruikt en wat ermee mag worden gedaan.It specifies what data you're allowed to access and what you can do with it. Autorisatie wordt soms afgekort tot 'AuthZ'.Authorization is sometimes shortened to AuthZ.

Azure Active Directory voor ontwikkel aars (v 1.0) (Azure AD) vereenvoudigt de verificatie voor toepassings ontwikkelaars door identiteit als service te bieden, met ondersteuning voor industrie-standaard protocollen zoals OAuth 2,0 en OpenID Connect Connect, evenals open-source-bibliotheken voor verschillende platformen, zodat u snel kunt beginnen met code ring.Azure Active Directory for developers (v1.0) (Azure AD) simplifies authentication for application developers by providing identity as a service, with support for industry-standard protocols such as OAuth 2.0 and OpenID Connect, as well as open-source libraries for different platforms to help you start coding quickly.

Er zijn twee primaire gebruiksscenario's in het Azure AD-programmeermodel:There are two primary use cases in the Azure AD programming model:

  • 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.During an OAuth 2.0 authorization grant flow - when the resource owner grants authorization to the client application, allowing the client to access the resource owner's resources.
  • 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.During resource access by the client - as implemented by the resource server, using the claims values present in the access token to make access control decisions based upon them.

Basis beginselen van verificatie in azure ADAuthentication basics in Azure AD

Bedenk het meest eenvoudige scenario waarin identiteiten zijn vereist: een gebruiker moet zich in een webbrowser verifiëren bij een webtoepassing.Consider the most basic scenario where identity is required: a user in a web browser needs to authenticate to a web application. In het volgende diagram is dit scenario te zien:The following diagram shows this scenario:

Overzicht van het aanmelden bij een webtoepassing

Dit is wat u moet weten over de verschillende onderdelen die in het diagram worden weer gegeven:Here's what you need to know about the various components shown in the diagram:

  • Azure AD is de identiteitsprovider.Azure AD is the identity provider. De ID-provider is verantwoordelijk voor het controleren van de identiteit van gebruikers en toepassingen die in de directory van een organisatie bestaan en geeft beveiligings tokens uit bij een geslaagde verificatie van deze gebruikers en toepassingen.The identity provider is responsible for verifying the identity of users and applications that exist in an organization's directory, and issues security tokens upon successful authentication of those users and applications.
  • Een toepassing die authenticatie aan Azure AD wil uitbesteden, moet zijn geregistreerd in Azure Active Directory (Azure AD).An application that wants to outsource authentication to Azure AD must be registered in Azure Active Directory (Azure AD). Azure AD registreert de app in de directory en geeft deze een unieke id.Azure AD registers and uniquely identifies the app in the directory.
  • Ontwikkelaars kunnen de open-sourceverificatiebibliotheken van Azure AD gebruiken om de verificatie te vereenvoudigen. Hierbij worden de protocolgegevens voor u verwerkt.Developers can use the open-source Azure AD authentication libraries to make authentication easy by handling the protocol details for you. Zie verificatie bibliotheken van micro soft Identity platform v 2.0 en v 1.0-verificatie bibliothekenvoor meer informatie.For more info, see Microsoft identity platform v2.0 authentication libraries and v1.0 authentication libraries.
  • Als een gebruiker eenmaal is geverifieerd, moet de toepassing het beveiligings token van de gebruiker valideren om ervoor te zorgen dat de verificatie is geslaagd.Once a user has been authenticated, the application must validate the user's security token to ensure that authentication was successful. U kunt snelstartgidsen, zelfstudies, codevoorbeelden in verschillende talen en frameworks bekijken waarin u ziet wat de toepassing moet doen.You can find quickstarts, tutorials, and code samples in a variety of languages and frameworks which show what the application must do.
    • Om snel een app te bouwen en functionaliteit toe te voegen, zoals tokens ophalen, tokens vernieuwen, gebruikers aanmelden, bepaalde gebruikersgegevens weergeven, enzovoort, gaat u naar het gedeelte Snelstartgidsen in de documentatie.To quickly build an app and add functionality like getting tokens, refreshing tokens, signing in a user, displaying some user info, and more, see the Quickstarts section of the documentation.
    • Ga naar het gedeelte Zelfstudies van de documentatie voor uitgebreide, op scenario's gebaseerde procedures voor ontwikkelaarstaken (zoals toegangstokens verkrijgen en deze gebruiken in aanroepen naar de Microsoft Graph-API en andere API's en aanmelden met Microsoft implementeren in een traditionele webbrowser-app via OpenID Connect).To get in-depth, scenario-based procedures for top auth developer tasks like obtaining access tokens and using them in calls to the Microsoft Graph API and other APIs, implementing sign-in with Microsoft with a traditional web browser-based app using OpenID Connect, and more, see the Tutorials section of the documentation.
    • Ga naar GitHub om codevoorbeelden te downloaden.To download code samples, go to GitHub.
  • De stroom van aanvragen en antwoorden in het verificatieproces wordt bepaald aan de hand van het gebruikte verificatieprotocol, zoals OAuth 2.0, OpenID Connect, WS-Federation of SAML 2.0.The flow of requests and responses for the authentication process is determined by the authentication protocol that you used, such as OAuth 2.0, OpenID Connect, WS-Federation, or SAML 2.0. Zie de sectie concepten > Authentication Protocol (Engelstalig) in de documentatie voor meer informatie over protocollen.For more info about protocols, see the Concepts > Authentication protocol section of the documentation.

In het bovenstaande voorbeeldscenario kunt u apps classificeren aan de hand van deze twee rollen:In the example scenario above, you can classify the apps according to these two roles:

  • Apps die veilig toegang nodig hebben tot resourcesApps that need to securely access resources
  • Apps die zelf de rol van resource hebbenApps that play the role of the resource itself

Hoe elke stroom tokens en codes uitstraaltHow each flow emits tokens and codes

Afhankelijk van hoe uw client is gebouwd, kunnen er één (of meerdere) verificatie stromen worden gebruikt die worden ondersteund door Azure AD.Depending on how your client is built, it can use one (or several) of the authentication flows supported by Azure AD. Deze stromen kunnen een aantal tokens (id_tokens, vernieuwings tokens, toegangs tokens) en autorisatie codes produceren, en vereisen verschillende tokens om ze te laten werken.These flows can produce a variety of tokens (id_tokens, refresh tokens, access tokens) as well as authorization codes, and require different tokens to make them work. Dit diagram bevat een overzicht:This chart provides an overview:

StroomFlow NodigRequires id_tokenid_token toegangs tokenaccess token token vernieuwenrefresh token autorisatie codeauthorization code
Autorisatie code stroomAuthorization code flow xx xx xx xx
Impliciete stroomImplicit flow xx xx
Hybride OIDC-stroomHybrid OIDC flow xx xx
Aflossingen van token vernieuwenRefresh token redemption token vernieuwenrefresh token xx xx xx
Namens-stroomOn-behalf-of flow toegangs tokenaccess token xx xx xx
Client referentiesClient credentials x (alleen app)x (app-only)

Tokens die zijn uitgegeven via de impliciete modus, hebben een beperkte lengte omdat ze via de URL worden teruggestuurd naar de browser (waarbij response_mode query of fragment ).Tokens issued via the implicit mode have a length limitation due to being passed back to the browser via the URL (where response_mode is query or fragment). Voor sommige browsers geldt een limiet voor de grootte van de URL die in de browser balk kan worden geplaatst en die kan worden uitgevoerd als deze te lang is.Some browsers have a limit on the size of the URL that can be put in the browser bar and fail when it is too long. Daarom hebben deze tokens geen groups wids claims.Thus, these tokens do not have groups or wids claims.

Nu u bekend bent met de basisinformatie, kunt u verder lezen voor inzicht in het identiteit-app-model en de bijbehorende API, voor meer informatie over inrichten in Azure AD en voor koppelingen naar gedetailleerde informatie over algemene scenario's waar Azure AD ondersteuning voor biedt.Now that you have an overview of the basics, read on to understand the identity app model and API, how provisioning works in Azure AD, and links to detailed info about the common scenarios that Azure AD supports.

ToepassingsmodelApplication model

Azure AD vertegenwoordigt toepassingen met een specifiek model dat speciaal bedoeld is voor twee belangrijke functies:Azure AD represents applications following a specific model that's designed to fulfill two main functions:

  • De app identificeren op basis van de ondersteunde verificatieprotocollen - dit omvat het inventariseren van alle id's, URL's, geheimen en gerelateerde informatie die nodig is tijdens de verificatie.Identify the app according to the authentication protocols it supports - This involves enumerating all the identifiers, URLs, secrets, and related information that are needed at authentication time. Azure AD doet dan het volgende:Here, Azure AD:

    • Bewaart alle gegevens die nodig zijn om verificatie tijdens runtime te ondersteunen.Holds all the data required to support authentication at run time.
    • Bewaart alle gegevens om te beslissen welke resources een app mogelijk nodig heeft en of aanvragen moeten worden uitgevoerd (en onder welke omstandigheden).Holds all the data for deciding what resources an app might need to access and whether a given request should be fulfilled and under what circumstances.
    • Biedt de infrastructuur voor het implementeren van app-inrichting in de tenant van de app-ontwikkelaar en in andere Azure AD-tenants.Provides the infrastructure for implementing app provisioning within the app developer's tenant and to any other Azure AD tenant.
  • Verwerkt de gebruikerstoestemming tijdens het aanvragen van het token en maakt het dynamisch inrichten van apps in tenants mogelijk - Hier doet Azure AD het volgende:Handle user consent during token request time and facilitate the dynamic provisioning of apps across tenants - Here, Azure AD:

    • Stelt gebruikers en beheerders in staat om de app dynamisch toestemming te geven of weigeren om resources namens hen te gebruiken.Enables users and administrators to dynamically grant or deny consent for the app to access resources on their behalf.
    • Stelt beheerders in staat om te beslissen wat apps mogen doen, welke gebruikers gebruik mogen maken van specifieke apps en hoe de directoryresources kunnen worden benaderd.Enables administrators to ultimately decide what apps are allowed to do and which users can use specific apps, and how the directory resources are accessed.

In Azure AD beschrijft een toepassingsobject een toepassing als een abstracte entiteit.In Azure AD, an application object describes an application as an abstract entity. Ontwikkelaars werken met toepassingen.Developers work with applications. Tijdens de implementatie gebruikt Azure AD een specifiek toepassingsobject als blauwdruk om een service-principal te maken; deze vertegenwoordigt een concreet exemplaar van een toepassing binnen een directory of tenant.At deployment time, Azure AD uses a given application object as a blueprint to create a service principal, which represents a concrete instance of an application within a directory or tenant. De service-principal bepaalt wat de app daadwerkelijk kan doen in een specifieke doeldirectory, wie deze mag gebruiken, tot welke resources deze toegang heeft en meer.It's the service principal that defines what the app can actually do in a specific target directory, who can use it, what resources it has access to, and so on. Azure AD maakt op basis van toestemming een service-principal van een toepassingsobject.Azure AD creates a service principal from an application object through consent.

In het volgende diagram staat een vereenvoudigde Azure AD-inrichtingsstroom op basis van toestemming.The following diagram shows a simplified Azure AD provisioning flow driven by consent. Er bestaan twee tenants (A en B), waarbij Tenant A eigenaar is van de toepassing, en Tenant B de toepassing instantiëren via een service-principal.In it, two tenants exist (A and B), where tenant A owns the application, and tenant B is instantiating the application via a service principal.

Vereenvoudigde inrichtingsstroom op basis van toestemming

De inrichtingsstroom verloopt als volgt:In this provisioning flow:

  1. Een gebruiker van Tenant B probeert zich aan te melden bij de app. het autorisatie-eind punt vraagt een token voor de toepassing aan.A user from tenant B attempts to sign in with the app, the authorization endpoint requests a token for the application.
  2. De gebruikers referenties zijn verkregen en geverifieerd voor verificatieThe user credentials are acquired and verified for authentication
  3. De gebruiker wordt gevraagd toestemming te geven voor de app om toegang te krijgen tot Tenant BThe user is prompted to provide consent for the app to gain access to tenant B
  4. Azure AD gebruikt het toepassings object in Tenant A als een blauw druk voor het maken van een Service-Principal in Tenant BAzure AD uses the application object in tenant A as a blueprint for creating a service principal in tenant B
  5. De gebruiker ontvangt de aangevraagde tokenThe user receives the requested token

U kunt dit proces zo vaak herhalen als u wilt (voor andere tenants, zoals C, D, enzovoort).You can repeat this process as many times as you want for other tenants (C, D, and so on). Tenant A behoudt de blauw druk voor de app (toepassings object).Tenant A retains the blueprint for the app (application object). De gebruikers en beheerders van de andere tenants waarvoor de app toestemming heeft, behouden controle over wat de toepassing mag doen. Dit kan worden beheerd met het bijbehorende service-principalobject in elke tenant.Users and admins of all the other tenants where the app is given consent retain control over what the application is allowed to do through the corresponding service principal object in each tenant. Zie Application and Service Principal Objects in micro soft Identity platform(Engelstalig) voor meer informatie.For more information, see Application and service principal objects in Microsoft identity platform.

Claims in Azure AD-beveiligingstokensClaims in Azure AD security tokens

Beveiligingstokens (toegangs- en id-tokens) die worden uitgegeven door Azure AD bevatten claims of asserties van informatie over het onderwerp dat is geverifieerd.Security tokens (access and ID tokens) issued by Azure AD contain claims, or assertions of information about the subject that has been authenticated. Toepassingen kunnen voor verschillende taken gebruikmaken van claims, waaronder:Applications can use claims for various tasks, including:

  • Het token validerenValidate the token
  • De directorytenant van het onderwerp identificerenIdentify the subject's directory tenant
  • Gebruikersgegevens weergevenDisplay user information
  • De autorisatie van het onderwerp bepalenDetermine the subject's authorization

Welke claims aanwezig zijn in een bepaald beveiligingstoken, is afhankelijk van het type token, het type referentie dat is gebruikt om de gebruiker te verifiëren en de configuratie van de toepassing.The claims present in any given security token are dependent upon the type of token, the type of credential used to authenticate the user, and the application configuration.

In de onderstaande tabel staat een korte beschrijving van elk type claim dat door Azure AD wordt uitgegeven.A brief description of each type of claim emitted by Azure AD is provided in the table below. Zie het toegangs tokens en de id-tokens die zijn uitgegeven door Azure AD voor meer gedetailleerde informatie.For more detailed information, see the access tokens and ID tokens issued by the Azure AD.

ClaimClaim DescriptionDescription
Toepassings-idApplication ID Identificeert de toepassing die gebruikmaakt van het token.Identifies the application that is using the token.
DoelgroepAudience Identificeert de ontvangende resource waar het token voor is bedoeld.Identifies the recipient resource the token is intended for.
Application Authentication Context Class ReferenceApplication Authentication Context Class Reference Geeft aan hoe de client is geverifieerd (openbare client of vertrouwelijke client).Indicates how the client was authenticated (public client vs. confidential client).
VerificatiemomentAuthentication Instant Registreert de datum en tijd waarop de verificatie heeft plaatsgevonden.Records the date and time when the authentication occurred.
VerificatiemethodeAuthentication Method Geeft aan hoe het onderwerp van het token is geverifieerd (wachtwoord, certificaat, enzovoort).Indicates how the subject of the token was authenticated (password, certificate, etc.).
VoornaamFirst Name Biedt de naam van de gebruiker zoals ingesteld in Azure AD.Provides the given name of the user as set in Azure AD.
GroepenGroups Bevat de object-id's van de Azure AD-groepen waar de gebruiker lid van is.Contains object IDs of Azure AD groups that the user is a member of.
IdentiteitsproviderIdentity Provider Registreert de identiteitsprovider waarmee het onderwerp van het token is geverifieerd.Records the identity provider that authenticated the subject of the token.
Uitgegeven omIssued At Registreert de tijd waarop het token is uitgegeven (vaak gebruikt om te controleren hoe nieuw het token is).Records the time at which the token was issued, often used for token freshness.
VerlenerIssuer Identificeert de beveiligingstokenservice die het token heeft uitgegeven en de Azure AD-tenant.Identifies the STS that emitted the token as well as the Azure AD tenant.
AchternaamLast Name Biedt de achternaam van de gebruiker, zoals ingesteld in Azure AD.Provides the surname of the user as set in Azure AD.
NameName Biedt een voor mensen leesbare waarde waarmee het onderwerp van het token wordt geïdentificeerd.Provides a human readable value that identifies the subject of the token.
Object-idObject ID Bevat een onveranderbare, unieke id voor het onderwerp in Azure AD.Contains an immutable, unique identifier of the subject in Azure AD.
RollenRoles Bevat beschrijvende namen voor de Azure AD-toepassingsrollen die zijn toegewezen aan de gebruiker.Contains friendly names of Azure AD Application Roles that the user has been granted.
BereikScope Geeft aan welke machtigingen zijn verleend aan de clienttoepassing.Indicates the permissions granted to the client application.
OnderwerpSubject Geeft aan over welke principal het token informatie bevat.Indicates the principal about which the token asserts information.
Tenant-idTenant ID Bevat een onveranderbare, unieke id voor de directorytenant die het token heeft uitgegeven.Contains an immutable, unique identifier of the directory tenant that issued the token.
Levensduur van tokenToken Lifetime Definieert gedurende welke periode een token geldig is.Defines the time interval within which a token is valid.
User Principal NameUser Principal Name Bevat de user principal name van het onderwerp.Contains the user principal name of the subject.
VersieVersion Bevat het versienummer van het token.Contains the version number of the token.

Volgende stappenNext steps