Delen via

Toepassingen en gebruikers verifiëren met Microsoft Entra-id

  • Artikel

Een primaire Microsoft Entra ID-functie voor apps is verificatie, het proces waarbij gebruikers hun identiteit declareren met een persoonlijke id, zoals een gebruikersnaam of e-mailadres. Bewijs van de identiteit wordt verstrekt. Het bewijs kan een wachtwoord, meervoudige verificatieartefact, een biometrische of wachtwoordloze toestemming zijn.

In dit artikel wordt beschreven hoe toepassingen microsoft Entra-id gebruiken om gebruikers en toepassingen te verifiëren. Het is de derde in een reeks artikelen over hoe Onafhankelijke softwareontwikkelaars (ISV) hun toepassingen voor Microsoft Entra-id kunnen bouwen en optimaliseren. In deze reeks vindt u meer informatie over deze onderwerpen:

Tokens aanvragen

Toepassingen vragen een token aan bij Microsoft Entra-id. Nadat apps het token hebben ontvangen, kunnen ze de informatie in dat token gebruiken om de gebruiker te identificeren. Wanneer u bouwt op Microsoft Entra ID, kunnen gebruikers veel toepassingen verifiëren met één geregistreerd Microsoft Entra ID-account (SSO). Met de verificatiemethode voor eenmalige aanmelding kunnen gebruikers zich met één set referenties aanmelden bij meerdere onafhankelijke softwaresystemen.

Protocollen die ontwikkelaars kunnen gebruiken om een token aan te vragen bij Microsoft Entra ID, gebruiken een browser om de gebruiker te verbinden met de Website van Microsoft Entra ID. Met deze website kan de gebruiker een privégesprek voeren met Microsoft Entra ID. Een toepassing is geen deelnemer in dat privégesprek. Apps starten de Microsoft Entra ID-website waar de gebruiker het verificatieproces start. Nadat het verificatieproces is voltooid, stuurt Microsoft Entra ID de gebruiker terug naar de toepassing, met of zonder een token.

Het is belangrijk dat gebruikers zelden het verificatieproces moeten doorlopen. Hoe vaker gebruikers dit moeten doen, hoe meer ze vatbaar zijn voor aanvallen zoals phishingaanvallen.

Aanmeldingsprompts verminderen

Eenmalige aanmelding kan aanmeldingsprompts verminderen of elimineren. Ontwikkelaars spelen een belangrijke rol bij het verminderen en elimineren van aanmeldingsprompts. Alle apps moeten de browser delen die toegang heeft tot de Microsoft Entra ID-website waar de gebruikers het verificatieproces uitvoeren. Als uw app een browsertoepassing met één pagina (SPA) of web-app is, zijn er geen stappen voor ontwikkelaars vereist. Alle apps in de browser delen de browser. Ontwikkelaars moeten aanmeldingsprompts proactief verminderen of verwijderen voor systeemeigen toepassingen die worden uitgevoerd op desktops en mobiele apparaten.

De beste methode om aanmeldingsprompts te verminderen of te elimineren, is door Microsoft Authentication Libraries (MSAL) of een bibliotheek te gebruiken die is gebouwd op MSAL en brokerverificaties. Deze methode minimaliseert aanmeldingsprompts en biedt de meest naadloze ervaring. Als het bouwen op MSAL niet mogelijk is, moet uw toepassing de systeembrowser gebruiken om aanmeldingsprompts te minimaliseren.

Voor apps die worden uitgevoerd in iOS of Android, hebben mobiele platformproviders een aantal functionaliteit om deze ervaring naadlooser te maken. Google heeft richtlijnen voor Android-toepassingen met aangepaste Chrome-tabbladen. Apple heeft richtlijnen voor het verifiëren van een gebruiker via een webservice in iOS-toepassingen. Vermijd het gebruik van ingesloten WebViews, omdat het delen in apps of met de systeembrowser mogelijk niet is toegestaan.

De twee protocollen voor gebruikersverificatie zijn Security Assertion Markup Language (SAML) 2.0 en OpenID Connect (OIDC). Microsoft Entra ID ondersteunt apps volledig met beide protocollen, zodat ontwikkelaars er een kunnen kiezen op basis van hun vereisten.

Deze verwijzingen bevatten gedetailleerde ondersteuning voor Microsoft Entra ID SAML.

  • Microsoft Identity Platform maakt gebruik van het SAML-protocol als uitgangspunt voor microsoft Entra ID SAML-documentatie voor ontwikkelaars.
  • Het SAML-protocol voor eenmalige aanmelding is de verwijzing voor de SAML 2.0-verificatieaanvragen en -antwoorden die door Microsoft Entra ID worden ondersteund.
  • Federatiemetagegevens van Microsoft Entra beschrijven de federatiemetagegevens en metagegevenseindpunten voor tenantspecifieke en tenantonafhankelijke metagegevens. Hierin worden metagegevens voor SAML en de oudere WS-Federation-standaarden behandeld. Hoewel dit volledig wordt ondersteund, raden we WS-Federation niet aan voor nieuwe toepassingen.
  • Naslaginformatie over SAML 2.0-tokenclaims is de documentatie voor SAML-tokens (asserties) van Microsoft Entra ID.

Er zijn enkele beperkingen in de ondersteuning van Microsoft Entra ID SAML. U kunt met name geen apps migreren waarvoor deze protocolmogelijkheden zijn vereist: ondersteuning voor het WS-Trust ActAs-patroon en samL-artefactomzetting.

Hoewel Microsoft Entra ID saml volledig ondersteunt voor apps die zijn gebouwd op het SAML-protocol, biedt het Microsoft Identity Platform geen bibliotheken of andere ontwikkelhulpprogramma's voor het ontwikkelen van toepassingen met SAML. Voor de ontwikkeling van nieuwe toepassingen raden we u aan OpenID Connect (OIDC) te gebruiken voor verificatie.

Microsoft Entra ID biedt volledige ondersteuning voor OpenID Connect. Microsoft biedt MSAL-, Microsoft Identity Web- en Azure SDK-bibliotheken om de ontwikkeling van OIDC-toepassingen te vereenvoudigen. OpenID Connect (OIDC) op het Microsoft Identity Platform bevat informatie over ondersteuning voor Microsoft Entra ID OIDC. MSAL ondersteunt automatisch OIDC. MSAL vraagt altijd een OIDC ID-token aan bij elke tokenaanvraag, inclusief autorisatieaanvragen voor een app voor toegang tot een resource.

Levensduur van token

MSAL slaat id-tokens en toegangstokens in de cache op op basis van de verlooptijd van het toegangstoken. Omdat microsoft Entra-id de levensduur van id-tokens en toegangstokens anders instelt, ontvangt u mogelijk een verlopen ID-token van een verlopen MSAL-cache terwijl het toegangstoken nog steeds binnen de geldige levensduur valt.

MSAL verlengt id-tokens niet automatisch. MSAL vernieuwt toegangstokens op of bijna het einde van de levensduur voor het toegangstoken wanneer een toepassing het token aanvraagt. Op dat moment vraagt MSAL een nieuw id-token aan. Als u OIDC wilt implementeren, gebruikt u de exp claim (verlopen) in het ID-token om een id-tokenaanvraag te plannen met behulp van de ForceRefresh vlag in MSAL.

Wanneer u bouwt op MSAL of een bibliotheek die is gebouwd op MSAL niet mogelijk is, kunt u de OpenID Connect-standaard gebruiken om de huidige gebruiker te verifiëren. Sommige functionaliteit in systeemeigen toepassingen is mogelijk niet mogelijk zonder MSAL te gebruiken, zoals ervoor zorgen dat de systeemeigen app wordt uitgevoerd op een beheerd apparaat. Raadpleeg Verhoog de tolerantie van verificatie en autorisatie in clienttoepassingen die u ontwikkelt voor richtlijnen wanneer u niet bouwt op MSAL.

Microsoft Entra ID implementeert een UserInfo-eindpunt als onderdeel van microsoft Entra ID OIDC-standaarden met een specifiek Microsoft Graph-pad (https://graph.microsoft.com/oidc/userinfo). Het is niet mogelijk om de informatie die het UserInfo eindpunt retourneert, toe te voegen of aan te passen. Omdat de informatie in het id-token een superset is van de informatie die wordt geretourneerd door het UserInfo eindpunt aan te roepen, raden we u aan het id-token te gebruiken in plaats van het UserInfo eindpunt aan te roepen.

Gebruikers verifiëren

Toepassingen communiceren met Microsoft Entra ID-tenants om gebruikers te verifiëren. Als u een gebruiker wilt verifiëren, stuurt een toepassing een browser naar https://login.microsoftonline.com/{tenant}/v2.0, waar {tenant} is de id of het domein van de tenant. Het is echter raadzaam dat ISV's Microsoft Entra ID gebruiken om multitenant-toepassingen te bouwen die het breedste scala aan klanten kunnen ondersteunen. Voor een multitenant-toepassing weet een app mogelijk pas van welke tenant een gebruiker afkomstig is nadat de gebruiker zich heeft geverifieerd, zodat het niet mogelijk is om een specifiek tenanteindpunt te gebruiken.

Als u multitenant-apps wilt inschakelen, biedt Microsoft Entra ID twee tenantonafhankelijke OIDC/OAuth 2.0-eindpunten:

  • https://login.microsoftonline.com/common/v2.0 staat gebruikers toe een app te verifiëren wanneer ze afkomstig zijn van een Microsoft Entra ID-tenant of die een Microsoft-account voor consumenten hebben van sites zoals outlook.com, skype.com, xbox.com, live.com of Hotmail.com.
  • https://login.microsoftonline.com/organizations/v2.0 staat gebruikers toe om een app te verifiëren wanneer ze afkomstig zijn van een Microsoft Entra ID-tenant.

Met deze eindpunten kan elke gebruiker van elke Microsoft Entra ID-tenant uw toepassing verifiëren. Als u alleen gebruikers van specifieke tenants wilt toestaan, implementeert u de logica om alleen gebruikers van die tenants toegang te geven tot uw app. De normale implementatie is om gebruikers te filteren op basis van de iss claim (verlener) of tid (tenant-id) in het token naar een acceptatielijst met tenants die u onderhoudt.

Microsoft Entra ID-tenants ondersteunen gebruikers die gewone leden van de tenant kunnen zijn of die gastgebruikers van de tenant kunnen zijn. Standaard zijn er beperkte mogelijkheden voor gastgebruikers in een tenant. Gastgebruikers kunnen bijvoorbeeld het volledige profiel van andere gebruikers in de tenant niet zien. Gastgebruikers, ook wel B2B-gebruikers (Business to Business) genoemd, stellen verschillende organisaties in staat om samen te werken met hulpprogramma's en services die door Microsoft Entra ID worden beveiligd. Een voorbeeldscenario is het uitnodigen van een gebruiker van buiten uw organisatie voor toegang tot een SharePoint-bestand in uw tenant. Normaal gesproken gebruikt een B2B-gebruiker zijn of haar e-mailadres als hun userid. Ze kunnen echter hetzelfde adres gebruiken als de in hun userid woningtenant. Microsoft Entra ID ondertekent de gebruiker standaard bij zijn of haar thuistenant wanneer hij of zij zijn of haar useridinvoert.

Als u een gebruiker wilt aanmelden als B2B-gebruiker, moet een toepassing het specifieke tenanteindpunt gebruiken waar de gebruiker een gast is. Hoewel het mogelijk is dat een gebruiker een tenant opgeeft waartoe ze toegang willen wanneer een toepassing het https://login.microsoftonline.com/organizations/v2.0 eindpunt gebruikt, kunnen gebruikers deze mogelijkheid moeilijk vinden om te detecteren.

Volgende stappen