Stöd för autentiseringsflöde i MSAL

Microsoft Authentication Library (MSAL) stöder flera auktoriseringsbidrag och associerade tokenflöden för användning av olika programtyper och scenarier.

Autentiseringsflöde	Gör	Programtyper som stöds
Auktoriseringskod	Användarens inloggning och åtkomst till webb-API:er för användarens räkning.	Skrivbordet Mobil Ensidesapp (SPA) (kräver PKCE) Webb
Klientautentiseringsuppgifter	Åtkomst till webb-API:er med hjälp av själva programmets identitet. Används vanligtvis för server-till-server-kommunikation och automatiserade skript som inte kräver någon användarinteraktion.	Daemon
Enhetskod	Användarinloggning och åtkomst till webb-API:er för användarens räkning på indatabegränsade enheter som smarta TV-apparater och IoT-enheter. Används också av CLI-program (Command Line Interface).	Desktop, Mobile
Implicit beviljande	Användarens inloggning och åtkomst till webb-API:er för användarens räkning. Det implicita beviljandeflödet rekommenderas inte längre – använd auktoriseringskod med PKCE i stället.	* Ensidesapp (SPA) * Webb
Å OBO:s vägnar	Åtkomst från ett "överordnat" webb-API till ett "nedströms"-webb-API för användarens räkning. Användarens identitet och delegerade behörigheter skickas vidare till det underordnade API:et från det överordnade API:et.	Webb-API
Användarnamn/lösenord (ROPC)	Tillåter att ett program loggar in användaren genom att direkt hantera deras lösenord. ROPC-flödet rekommenderas INTE.	Desktop, Mobile
Integrerad Windows-autentisering (IWA)	Tillåter att program på domän- eller Microsoft Entra-anslutna datorer hämtar en token tyst (utan interaktion med användargränssnittet från användaren).	Desktop, Mobile

Token

Ditt program kan använda ett eller flera autentiseringsflöden. Varje flöde använder vissa tokentyper för autentisering, auktorisering och tokenuppdatering, och vissa använder även en auktoriseringskod.

Autentiseringsflöde eller åtgärd	Kräver	ID-token	Åtkomsttoken	Uppdateringstoken	Auktoriseringskod
Auktoriseringskodflöde
Klientautentiseringsuppgifter			(endast app)
Enhetskodflöde
Implicit flöde
On-Behalf-Of-flöde	åtkomsttoken
Användarnamn/lösenord (ROPC)	användarnamn, lösenord
Hybrid-OIDC-flöde
Inlösen av uppdateringstoken	uppdateringstoken

Interaktiv och icke-interaktiv autentisering

Flera av dessa flöden stöder både interaktivt och icke-interaktivt tokenförvärv.

• Interaktiv – Användaren kan uppmanas att ange indata från auktoriseringsservern. Om du till exempel vill logga in, utföra multifaktorautentisering (MFA) eller ge medgivande till fler behörigheter för resursåtkomst.
• Icke-interaktiv (tyst) – Användaren kanske inte uppmanas att ange indata. Programmet kallas även för "tyst" tokenförvärv och försöker hämta en token med hjälp av en metod där auktoriseringsservern kanske inte uppmanar användaren att ange indata.

Ditt MSAL-baserade program bör först försöka hämta en token tyst och återgå till den interaktiva metoden endast om det icke-interaktiva försöket misslyckas. Mer information om det här mönstret finns i Hämta och cachelagrar token med hjälp av Microsoft Authentication Library (MSAL).

Auktoriseringskod

OAuth 2.0-auktoriseringskoden kan användas av webbappar, ensidesappar (SPA) och interna appar (mobil och skrivbord) för att få åtkomst till skyddade resurser som webb-API:er.

När användare loggar in på webbprogram får programmet en auktoriseringskod som det kan lösa in för en åtkomsttoken för att anropa webb-API:er.

I följande diagram, programmet:

1. Begär en auktoriseringskod som löstes in för en åtkomsttoken
2. Använder åtkomsttoken för att anropa ett webb-API, Microsoft Graph

Begränsningar för auktoriseringskod

• Ensidesprogram kräver proof key for Code Exchange (PKCE) när du använder auktoriseringskodens beviljandeflöde. PKCE stöds av MSAL.

• OAuth 2.0-specifikationen kräver att du använder en auktoriseringskod för att endast lösa in en åtkomsttoken en gång.

  Om du försöker hämta åtkomsttoken flera gånger med samma auktoriseringskod returneras ett fel som liknar följande av Microsofts identitetsplattform. Vissa bibliotek och ramverk begär auktoriseringskoden automatiskt, och att begära en kod manuellt i sådana fall resulterar också i det här felet.

  AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.
  

Klientautentiseringsuppgifter

Med OAuth 2.0-klientens autentiseringsuppgifter kan du komma åt webbaserade resurser med hjälp av identiteten för ett program. Den här beviljandetypen används ofta för server-till-server-interaktioner som måste köras i bakgrunden, utan direkt interaktion med en användare. Dessa typer av program kallas ofta för daemon eller tjänstkonton.

Med beviljandeflödet för klientautentiseringsuppgifter kan en webbtjänst (en konfidentiell klient) använda sina egna autentiseringsuppgifter, i stället för att personifiera en användare, för att autentisera när en annan webbtjänst anropas. I det här scenariot är klienten vanligtvis en webbtjänst på mellannivå, en daemontjänst eller en webbplats. För en högre säkerhetsnivå tillåter Microsofts identitetsplattform även att den anropande tjänsten använder ett certifikat (i stället för en delad hemlighet) som autentiseringsuppgifter.

Programhemligheter

I följande diagram, programmet:

1. Hämtar en token med hjälp av autentiseringsuppgifter för programhemlighet eller lösenord
2. Använder token för att göra begäranden om resursen

Certifikat

I följande diagram, programmet:

1. Hämtar en token med hjälp av certifikatautentiseringsuppgifter
2. Använder token för att göra begäranden om resursen

Dessa klientautentiseringsuppgifter måste vara:

• Registrerad med Microsoft Entra-ID
• Skickades in när du skapade det konfidentiella klientprogramobjektet i koden

Begränsningar för klientautentiseringsuppgifter

Det konfidentiella klientflödet stöds inte på mobila plattformar som Android, iOS eller UWP. Mobilprogram anses vara offentliga klientprogram som inte kan garantera konfidentialiteten för sina autentiseringsuppgifter.

Enhetskod

Med OAuth 2.0-enhetskodflödet kan användare logga in på indatabegränsade enheter som smarta TV-apparater, IoT-enheter och skrivare. Interaktiv autentisering med Microsoft Entra-ID kräver en webbläsare. Om enheten eller operativsystemet inte tillhandahåller någon webbläsare tillåter enhetskodflödet att användaren använder en annan enhet som en dator eller mobiltelefon för att logga in interaktivt.

Genom att använda enhetskodflödet hämtar programmet token via en tvåstegsprocess som är utformad för dessa enheter och operativsystem. Exempel på sådana program är de som körs på IoT-enheter och CLI-verktyg (command-line interface).

I följande diagram:

1. När användarautentisering krävs tillhandahåller appen en kod och ber användaren att använda en annan enhet som en internetansluten smartphone för att besöka en URL (till exempel https://microsoft.com/devicelogin). Användaren uppmanas sedan att ange koden och fortsätta med en normal autentiseringsupplevelse, inklusive medgivandemeddelanden och multifaktorautentisering, om det behövs.
2. Vid lyckad autentisering tar kommandoradsappen emot nödvändiga token via en backkanal och använder dem för att utföra de webb-API-anrop som krävs.

Begränsningar för enhetskod

• Enhetskodflödet är endast tillgängligt för offentliga klientprogram.
• När du initierar ett offentligt klientprogram i MSAL använder du något av följande utfärdarformat:
  • Klientorganisation: https://login.microsoftonline.com/{tenant}/, där {tenant} är antingen klientorganisations-ID:t eller ett domännamn som är associerat med klientorganisationen.
  • Arbets- och skolkonton: https://login.microsoftonline.com/organizations/.

Implicit beviljande

Det implicita beviljandeflödet har ersatts av auktoriseringskodflödet med PKCE som önskat och säkrare flöde för tokenbeviljande för program på en sida på klientsidan (SPA). Vi rekommenderar inte längre att du använder det implicita beviljandeflödet. Om du skapar ett SPA använder du auktoriseringskodflödet med PKCE i stället.

Ensideswebbappar som skrivits i JavaScript (inklusive ramverk som Angular, Vue.js eller React.js) laddas ned från servern och koden körs direkt i webbläsaren. Eftersom deras kod på klientsidan körs i webbläsaren och inte på en webbserver, har de andra säkerhetsegenskaper än traditionella webbprogram på serversidan. Innan tillgängligheten för Proof Key for Code Exchange (PKCE) för auktoriseringskodflödet användes det implicita beviljandeflödet av SPA:er för bättre svarstider och effektivitet vid hämtar åtkomsttoken.

Med implicit beviljandeflöde för OAuth 2.0 kan appen hämta åtkomsttoken från Microsofts identitetsplattform utan att utföra ett utbyte av serverautentiseringsuppgifter på serversidan. Det implicita beviljandeflödet gör att en app kan logga in användaren, underhålla en session och hämta token för andra webb-API:er inifrån JavaScript-koden som laddas ned och körs av användaragenten (vanligtvis en webbläsare).

Begränsningar för implicit beviljande

Det implicita beviljandeflödet inkluderar inte programscenarier som använder plattformsoberoende JavaScript-ramverk som Electron eller React Native. Plattformsoberoende ramverk som dessa kräver ytterligare funktioner för interaktion med de interna skrivbords- och mobilplattformar som de körs på.

Token som utfärdas via implicit flödesläge har en längdbegränsning eftersom de returneras till webbläsaren via URL (där response_mode är antingen query eller fragment). Vissa webbläsare begränsar längden på URL:en i webbläsarfältet och misslyckas när den är för lång. Därför innehåller groups inte dessa implicita flödestoken eller wids anspråk.

Å OBO:s vägnar

Flödesflödet OAuth 2.0 för autentisering används när ett program anropar en tjänst eller ett webb-API som i sin tur behöver anropa en annan tjänst eller ett annat webb-API. Tanken är att sprida den delegerade användaridentiteten och behörigheterna via begärandekedjan. För att mellannivåtjänsten ska kunna göra autentiserade begäranden till den underordnade tjänsten måste den skydda en åtkomsttoken från Microsofts identitetsplattform för användarens räkning.

I följande diagram:

1. Programmet hämtar en åtkomsttoken för webb-API:et.
2. En klient (webb-, skrivbords-, mobil- eller ensidesprogram) anropar ett skyddat webb-API och lägger till åtkomsttoken som en ägartoken i autentiseringshuvudet för HTTP-begäran. Webb-API:et autentiserar användaren.
3. När klienten anropar webb-API:et begär webb-API:et en annan token åt användaren.
4. Det skyddade webb-API:et använder den här token för att anropa ett underordnat webb-API för användaren. Webb-API:et kan också senare begära token för andra underordnade API:er (men fortfarande för samma användares räkning).

Användarnamn/lösenord (ROPC)

Varning

Flödet för autentiseringsuppgifter för resursägarens lösenord (ROPC) rekommenderas INTE. ROPC kräver en hög grad av förtroende och exponering av autentiseringsuppgifter. Använd endast ROPC om ett säkrare flöde inte kan användas. Mer information finns i Vad är lösningen på det växande problemet med lösenord?.

Med OAuth 2.0-resursägarens lösenordsuppgifter (ROPC) kan ett program logga in användaren genom att direkt hantera sitt lösenord. I ditt skrivbordsprogram kan du använda flödet användarnamn/lösenord för att hämta en token tyst. Inget användargränssnitt krävs när du använder programmet.

Vissa programscenarier som DevOps kan vara användbara för ROPC, men du bör undvika det i alla program där du tillhandahåller ett interaktivt användargränssnitt för användarinloggning.

I följande diagram, programmet:

1. Hämtar en token genom att skicka användarnamnet och lösenordet till identitetsprovidern
2. Anropar ett webb-API med hjälp av token

Om du vill hämta en token tyst på Windows domänanslutna datorer rekommenderar vi integrerad Windows-autentisering (IWA) i stället för ROPC. I andra scenarier använder du enhetskodflödet.

Begränsningar för ROPC

Följande begränsningar gäller för program som använder ROPC-flödet:

• Enkel inloggning stöds inte.
• Multifaktorautentisering (MFA) stöds inte.
  • Kontakta klientadministratören innan du använder det här flödet – MFA är en vanlig funktion.
• Villkorlig åtkomst stöds inte.
• ROPC fungerar endast för arbets- och skolkonton.
• Personliga Microsoft-konton (MSA) stöds inte av ROPC.
• ROPC stöds i .NET Desktop- och ASP.NET Core-program.
• ROPC stöds inte i Universell Windows-plattform-program (UWP).
• ROPC i Azure AD B2C stöds endast för lokala konton.
  • Information om ROPC i MSAL.NET och Azure AD B2C finns i Använda ROPC med Azure AD B2C.

Integrerad Windows-autentisering (IWA)

MSAL stöder integrerad Windows-autentisering (IWA) för skrivbords- och mobilprogram som körs på domänanslutna eller Microsoft Entra-anslutna Windows-datorer. Genom att använda IWA hämtar dessa program en token tyst utan att användaren behöver använda användargränssnittet.

I följande diagram, programmet:

1. Hämtar en token med hjälp av integrerad Windows-autentisering
2. Använder token för att göra begäranden om resursen

Begränsningar för IWA

Kompatibilitet

Integrerad Windows-autentisering (IWA) är aktiverat för .NET Desktop-, .NET- och Windows Universal Platform-appar.

IWA stöder endast AD FS-federerade användare – användare som skapats i Active Directory och backas upp av Microsoft Entra-ID. Användare som skapats direkt i Microsoft Entra-ID utan Active Directory-stöd (hanterade användare) kan inte använda det här autentiseringsflödet.

Multifaktorautentisering (MFA)

IWA:s icke-interaktiva (tyst) autentisering kan misslyckas om MFA är aktiverat i Microsoft Entra-klientorganisationen och en MFA-utmaning utfärdas av Microsoft Entra ID. Om IWA misslyckas bör du återgå till en interaktiv autentiseringsmetod enligt beskrivningen tidigare.

Microsoft Entra-ID använder AI för att avgöra när tvåfaktorautentisering krävs. Tvåfaktorautentisering krävs vanligtvis när en användare loggar in från ett annat land/en annan region, när den är ansluten till ett företagsnätverk utan att använda ett VPN, och ibland när de är anslutna via ett VPN. Eftersom MFA:s konfigurations- och utmaningsfrekvens kan ligga utanför din kontroll som utvecklare bör ditt program hantera ett fel i IWA:s tyst tokenförvärv.

URI-begränsningar för utfärdare

Den utfärdare som skickades in när det offentliga klientprogrammet skapades måste vara något av:

• https://login.microsoftonline.com/{tenant}/ – Den här utfärdaren anger ett program med en klientorganisation vars inloggningspublik är begränsad till användarna i den angivna Microsoft Entra-klientorganisationen. Värdet {tenant} kan vara klientorganisations-ID i GUID-formulär eller det domännamn som är associerat med klientorganisationen.
• https://login.microsoftonline.com/organizations/ – Den här utfärdaren anger ett program med flera klientorganisationer vars inloggningspublik är användare i alla Microsoft Entra-klientorganisationer.

Utfärdarvärden får INTE innehålla /common eller /consumers eftersom personliga Microsoft-konton (MSA) inte stöds av IWA.

Krav för medgivande

Eftersom IWA är ett tyst flöde:

• Användaren av ditt program måste tidigare ha samtyckt till att använda programmet.

  OR

• Klientadministratören måste tidigare ha samtyckt till att alla användare i klientorganisationen använder programmet.

För att uppfylla något av kraven måste en av dessa åtgärder ha slutförts:

• Du som programutvecklare har valt Bevilja i Azure-portalen själv.
• En klientadministratör har valt Bevilja/återkalla administratörsmedgivande för {klientdomän} på fliken API-behörigheter i appregistreringen i Azure-portalen. Mer information finns i Lägga till behörigheter för åtkomst till webb-API:et.
• Du har gett användarna ett sätt att samtycka till programmet. se Användarmedgivande.
• Du har gett klientadministratören ett sätt att samtycka till programmet. se Administratörsmedgivande.

Mer information om medgivande finns i Behörigheter och medgivande.

Gå vidare

Lär dig mer om att hämta och cachelagra de token som används i dessa flöden:

Hämta och cachelagrar token med hjälp av Microsoft Authentication Library (MSAL)