Programtyper för Microsofts identitetsplattform

Microsofts identitetsplattform stöder autentisering för olika moderna apparkitekturer, som alla baseras på branschstandardprotokollen OAuth 2.0 eller OpenID Anslut. Den här artikeln beskriver de typer av appar som du kan skapa med hjälp av Microsofts identitetsplattform, oavsett vilket språk eller plattform du föredrar. Informationen är utformad för att hjälpa dig att förstå scenarier på hög nivå innan du börjar arbeta med koden i programscenarierna.

Grunderna

Du måste registrera varje app som använder Microsofts identitetsplattform i administrationscentret för Microsoft Entra Appregistreringar. Appregistreringsprocessen samlar in och tilldelar dessa värden för din app:

• Ett program-ID (klient)-ID som unikt identifierar din app
• En omdirigerings-URI som du kan använda för att dirigera tillbaka svar till din app
• Några andra scenariospecifika värden, till exempel kontotyper som stöds

Mer information finns i hur du registrerar en app.

När appen har registrerats kommunicerar appen med Microsofts identitetsplattform genom att skicka begäranden till slutpunkten. Vi tillhandahåller ramverk och bibliotek med öppen källkod som hanterar information om dessa begäranden. Du har också möjlighet att implementera autentiseringslogik själv genom att skapa begäranden till dessa slutpunkter:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

Apptyperna som stöds av Microsofts identitetsplattform är;

• Ensidesapplikation (SPA)
• Webbapp
• Webb-API
• Mobila och interna appar
• Tjänst, daemon, skript

Enkelsidiga appar

Många moderna appar har en ensidesapp (SPA) som främst skrivs i JavaScript, ofta med ett ramverk som Angular, React eller Vue. Microsofts identitetsplattform stöder dessa appar med hjälp av OpenID Anslut-protokollet för autentisering och en av två typer av auktoriseringsbidrag som definieras av OAuth 2.0. De beviljandetyper som stöds är antingen det implicita OAuth 2.0-beviljandeflödet eller den nyare OAuth 2.0-auktoriseringskoden + PKCE-flödet (se nedan).

Flödesdiagrammet visar OAuth 2.0-auktoriseringskodens beviljandeflöde (med information om PKCE utelämnat), där appen tar emot en kod från Microsofts identitetsplattform authorize slutpunkten och löser in den mot en åtkomsttoken och en uppdateringstoken med hjälp av webbförfrågningar mellan webbplatser. För SPA:er är åtkomsttoken giltig i 1 timme och när den har upphört att gälla måste du begära en annan kod med hjälp av uppdateringstoken. Förutom åtkomsttoken begärs vanligtvis även en id_token som representerar den inloggade användaren i klientprogrammet via samma flöde och/eller en separat OpenID-Anslut begäran (visas inte här).

Om du vill se detta i praktiken läser du Snabbstart: Logga in användare i en ensidesapp (SPA) och anropa Microsoft Graph API med JavaScript.

Auktoriseringskodflöde jämfört med implicit flöde

OAuth 2.0-auktoriseringskodflödet är nu det rekommenderade sättet att skapa SPA:er för att säkerställa appens kompatibilitet i Safari och andra sekretessmedvetna webbläsare. Efter borttagningen av cookies från tredje part och större uppmärksamhet rekommenderas inte fortsatt användning av det implicita flödet.

Webbappar

För webbappar (.NET, PHP, Java, Ruby, Python, Node) som användaren kommer åt via en webbläsare kan du använda OpenID-Anslut för användarinloggning. I OpenID Anslut tar webbappen emot en ID-token. En ID-token är en säkerhetstoken som verifierar användarens identitet och ger information om användaren i form av anspråk:

// Partial raw ID token
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...

// Partial content of a decoded ID token
{
    "name": "Casey Jensen",
    "email": "casey.jensen@onmicrosoft.com",
    "oid": "ab12cd34-effe-5678-9012-abcdef012345"
    ...
}

Mer information om olika typer av token som används i Microsofts identitetsplattform finns i referensen för åtkomsttoken och id_token referens.

I webbserverappar utför inloggningsautentiseringsflödet följande övergripande steg:

Du kan säkerställa användarens identitet genom att verifiera ID-token med en offentlig signeringsnyckel som tas emot från Microsofts identitetsplattform. En sessionscookie har angetts, som kan användas för att identifiera användaren vid efterföljande sidbegäranden.

Läs mer genom att skapa en ASP.NET Core-webbapp som loggar in användare i följande självstudieserie i flera delar

Förutom enkel inloggning kan en webbserverapp behöva komma åt en annan webbtjänst, till exempel ett REST-API (Representational State Transfer). I det här fallet använder webbserverappen ett kombinerat OpenID-Anslut- och OAuth 2.0-flöde med hjälp av OAuth 2.0-auktoriseringskodflödet. Mer information om det här scenariot finns i vårt kodexempel.

Webb-API:er

Du kan använda Microsofts identitetsplattform för att skydda webbtjänster, till exempel appens RESTful-webb-API. Webb-API:er kan implementeras på flera plattformar och språk. De kan också implementeras med hjälp av HTTP-utlösare i Azure Functions. I stället för ID-token och sessionscookies använder ett webb-API en OAuth 2.0-åtkomsttoken för att skydda sina data och autentisera inkommande begäranden.

Anroparen för ett webb-API lägger till en åtkomsttoken i auktoriseringshuvudet för en HTTP-begäran, så här:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...
Accept: application/json
...

Webb-API:et använder åtkomsttoken för att verifiera API-anroparens identitet och för att extrahera information om anroparen från anspråk som kodas i åtkomsttoken. Mer information om olika typer av token som används i Microsofts identitetsplattform finns i referensen för åtkomsttoken och ID-tokenreferensen.

Ett webb-API kan ge användarna möjlighet att välja eller välja bort specifika funktioner eller data genom att exponera behörigheter, även kallade omfång. För att en anropande app ska få behörighet till ett omfång måste användaren godkänna omfånget under ett flöde. Microsofts identitetsplattform ber användaren om behörighet och registrerar sedan behörigheter i alla åtkomsttoken som webb-API:et tar emot. Webb-API:et verifierar de åtkomsttoken som den tar emot vid varje anrop och utför auktoriseringskontroller.

Ett webb-API kan ta emot åtkomsttoken från alla typer av appar, inklusive webbserverappar, skrivbords- och mobilappar, ensidesappar, daemoner på serversidan och även andra webb-API:er. Flödet på hög nivå för ett webb-API ser ut så här:

Om du vill lära dig hur du skyddar ett webb-API med hjälp av OAuth2-åtkomsttoken kan du läsa kodexemplen för webb-API:et i självstudien om skyddat webb-API.

I många fall måste även webb-API:er göra utgående begäranden till andra underordnade webb-API:er som skyddas av Microsofts identitetsplattform. För att göra det kan webb-API:er dra nytta av OBO-flödet (On-Behalf-Of), som gör att webb-API:et kan utbyta en inkommande åtkomsttoken för att en annan åtkomsttoken ska användas i utgående begäranden. Mer information finns i flödet Microsofts identitetsplattform och OAuth 2.0 On-Behalf-Of.

Mobila och interna appar

Enhetsinstallerade appar, till exempel mobilappar och skrivbordsappar, behöver ofta komma åt serverdelstjänster eller webb-API:er som lagrar data och utför funktioner åt en användare. Dessa appar kan lägga till inloggning och auktorisering till serverdelstjänster med hjälp av OAuth 2.0-auktoriseringskodflödet.

I det här flödet får appen en auktoriseringskod från Microsofts identitetsplattform när användaren loggar in. Auktoriseringskoden representerar appens behörighet att anropa serverdelstjänster för den användare som är inloggad. Appen kan byta auktoriseringskoden i bakgrunden mot en OAuth 2.0-åtkomsttoken och en uppdateringstoken. Appen kan använda åtkomsttoken för att autentisera till webb-API:er i HTTP-begäranden och använda uppdateringstoken för att hämta nya åtkomsttoken när äldre åtkomsttoken upphör att gälla.

Kommentar

Om programmet använder standardsystemwebbvyn kontrollerar du informationen om funktionen "Bekräfta min inloggning" och felkoden AADSTS50199 i Felkoder för Microsoft Entra-autentisering och auktorisering.

Server, daemon och skript

Appar som har långvariga processer eller som fungerar utan interaktion med en användare behöver också ett sätt att komma åt skyddade resurser, till exempel webb-API:er. Dessa appar kan autentisera och hämta token med hjälp av appens identitet, i stället för en användares delegerade identitet, med OAuth 2.0-klientens autentiseringsuppgifter. Du kan bevisa appens identitet med hjälp av en klienthemlighet eller ett certifikat. Mer information finns i Daemon-konsolprogrammet för .NET med hjälp av Microsofts identitetsplattform.

I det här flödet interagerar appen direkt med /token slutpunkten för att få åtkomst:

Om du vill skapa en daemonapp kan du läsa dokumentationen om klientautentiseringsuppgifter eller prova en .NET-exempelapp.

Se även

Nu när du är bekant med de typer av program som stöds av Microsofts identitetsplattform kan du läsa mer om OAuth 2.0 och OpenID Anslut för att få en förståelse för de protokollkomponenter som används av de olika scenarierna.