Programtyper för Microsofts identitetsplattform

Microsofts identitetsplattform stöder autentisering för en mängd 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 Azure Portal Appregistreringar. Appregistreringsprocessen samlar in och tilldelar dessa värden för din app:

  • Ett program-ID (klient) 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 registrera 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 informationen 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

Ensidesappar (JavaScript)

Många moderna appar har en enkelsidig appklientdel som främst skrivits 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 antingen implicit OAuth 2.0-beviljandeflöde eller det nyare OAuth 2.0-auktoriseringskoden + PKCE-flödet för auktorisering (se nedan).

Flödesdiagrammet nedan visar beviljandet av OAuth 2.0-auktoriseringskod (med information om PKCE utelämnad), där appen tar emot en kod från Microsofts identitetsplattform-slutpunkten authorize och löser in den mot en åtkomsttoken och en uppdateringstoken med hjälp av webbförfrågningar mellan webbplatser. Åtkomsttoken upphör att gälla var 24:e timme och appen måste begära en annan kod med hjälp av uppdateringstoken. Förutom åtkomsttoken begärs vanligtvis 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).

Diagram showing the OAuth 2 authorization code flow between a single-page app and the security token service endpoint.

Om du vill se det här scenariot i praktiken kan du läsa Självstudie: Logga in användare och anropa Microsoft Graph API från ett JavaScript SPA med hjälp av autentiseringskodflödet.

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

Under större delen av historiken för OAuth 2.0 var det implicita flödet det rekommenderade sättet att skapa ensidesappar. Med borttagning av cookies från tredje part och större uppmärksamhet på säkerhetsproblem kring det implicita flödet har vi flyttat till auktoriseringskodflödet för ensidesappar.

För att säkerställa kompatibilitet för din app i Safari och andra sekretessmedvetna webbläsare rekommenderar vi inte längre användning av det implicita flödet och rekommenderar i stället auktoriseringskodflö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
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded ID token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

Ytterligare 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 steg på hög nivå:

Shows the web app authentication flow

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 anges, som kan användas för att identifiera användaren vid efterföljande sidförfrågningar.

Om du vill se det här scenariot i praktiken kan du prova kodexemplen i webbappen som loggar in användare.

Förutom enkel inloggning kan en webbserverapp behöva komma åt en annan webbtjänst, till exempel ett REST-API. 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 komma igång med webbappar och webb-API:er.

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 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 för att 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 eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
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 är kodade i åtkomsttoken. Mer information om olika typer av token som används i Microsofts identitetsplattform finns i referensen för åtkomsttoken och id_token referens.

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, skrivbordsappar och mobilappar, enkelsidiga appar, 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:

Shows the web API authentication flow

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 det skyddade webb-API:et.

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 on-behalf-of-flödet , vilket 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 för 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 utbyta auktoriseringskoden i bakgrunden mot en OAuth 2.0-åtkomsttoken och en uppdateringstoken. Appen kan använda åtkomsttoken för att autentisera mot 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.

Shows the native app authentication flow

Anteckning

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

Daemons och appar på serversidan

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 .NET Core-daemonkonsolprogrammet med Microsofts identitetsplattform.

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

Shows the daemon app authentication flow

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

Nästa steg

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.