Dela via

Lösenordsuppgifter för resursägare i Microsofts identitetsplattform och OAuth 2.0

  • Artikel

Microsofts identitetsplattform stöder OAuth 2.0 Resource Owner Password Credentials (ROPC) åtkomst, vilket gör att ett program kan logga in användaren genom att hantera deras lösenord direkt. Den här artikeln beskriver hur du programmerar direkt mot protokollet i ditt program. När det är möjligt rekommenderar vi att du använder Microsofts autentiseringsbibliotek (MSAL) som stöds i stället för att hämta tokens och anropa skyddade webb-API:er. Ta också en titt på de exempelappar som använder MSAL.

Varning

Microsoft rekommenderar att du inte använda ROPC-flödet. den är inte kompatibel med multifaktorautentisering (MFA). I de flesta scenarier är säkrare alternativ tillgängliga och rekommenderas. Det här flödet kräver en mycket hög grad av förtroende för programmet och medför risker som inte finns i andra flöden. Du bör bara använda det här flödet när säkrare flöden inte är livskraftiga.

Viktig

  • Microsofts identitetsplattform stöder endast ROPC-beviljandet inom Microsoft Entra-klientorganisationer, inte personliga konton. Det innebär att du måste använda en klientspecifik slutpunkt (https://login.microsoftonline.com/{TenantId_or_Name}) eller slutpunkten organizations.
  • Personliga konton som bjuds in till en Microsoft Entra-klient kan inte använda ROPC-flödet.
  • Konton som inte har lösenord kan inte logga in med ROPC, vilket innebär att funktioner som SMS-inloggning, FIDO och Authenticator-appen inte fungerar med det flödet. Om din app eller användare behöver dessa funktioner använder du en annan bidragstyp än ROPC.
  • Om användarna behöver använda multifaktorautentisering (MFA) för att logga in på programmet blockeras de i stället.
  • ROPC stöds inte i hybrididentitetsfederation scenarier (till exempel Microsoft Entra ID och AD FS som används för att autentisera lokala konton). Om användarna omdirigeras till en lokal identitetsprovider kan Microsoft Entra-ID:t inte testa användarnamnet och lösenordet mot identitetsprovidern. Genomgångsautentisering stöds dock med ROPC.
  • Ett undantag från ett hybrididentitetsfederationsscenario skulle vara följande: Princip för identifiering av hemsfär med AllowCloudPasswordValidation inställd på TRUE gör att ROPC-flödet kan fungera för federerade användare när ett lokalt lösenord synkroniseras till molnet. Mer information finns i Aktivera direkt ROPC-autentisering av federerade användare för äldre program.
  • Lösenord med inledande eller avslutande blanksteg stöds inte av ROPC-flödet.

Så här migrerar du bort från ROPC

I takt med att MFA blir vanligare accepterar vissa Microsoft-webb-API:er endast åtkomsttoken om de har godkänt MFA-kraven. Program och testriggar som förlitar sig på ROPC kommer att låsas ute. Microsoft Entra utfärdar antingen inte token eller så avvisar resursen begäran.

Om du använder ROPC för att hämta token för att anropa skyddade underordnade API:er, bör du migrera till en säker strategi för att anskaffa token.

När användarkontext är tillgänglig

Om en slutanvändare behöver komma åt en resurs bör klientprogrammet som agerar för deras räkning använda en form av interaktiv autentisering. Slutanvändaren kan bara utmanas för MFA när de uppmanas i webbläsaren.

  • För webbprogram:
  • Webb-API:er kan inte visa en webbläsare. I stället måste de returnera en utmaning tillbaka till klientapplikationen. Mer information finns i webb-API:er och utmaningar för användare i webb-API:er.
  • Datorprogram bör använda brokerbaserad autentisering. Mäklare använder webbläsarbaserad autentisering, så att de kan framtvinga MFA och även aktivera det säkraste säkerhetsläget möjligt.
  • Mobila applikationer bör också konfigureras för att använda brokerbaserad autentisering (Authenticator, Företagsportal).

När användarkontexten inte är tillgänglig

Exempel på scenarier där ingen användarkontext är inblandad kan vara, men inte begränsas till, följande:

  • Ett skript som körs som en del av en CI-pipeline.
  • En tjänst som behöver anropa en resurs för sig själv, utan användarinformation.

Programutvecklare bör använda tjänsthuvudautentisering, vilket illustreras i dæmonexempel. MFA gäller inte för Service Principals.

Det finns flera sätt att autentisera sig som tjänstprincipal.

  • Om din app körs i Azure-infrastrukturen använder du hanterad identitet. Hanterad identitet eliminerar kostnaderna för att underhålla och rotera hemligheter och certifikat.
  • Om appen körs på ett system som hanteras av en annan OAuth2-kompatibel identitetsprovider, till exempel GitHub, använder du federerade identitetsuppgifter.
  • Om du inte kan använda en hanterad identitet eller en federerad identitet använder du en certifikatautentiseringsuppgifter.

Varning

Använd inte autentisering med tjänstens huvudnamn när en användarkontext är tillgänglig. App-åtkomst är i sig högprivilegierad, vilket ofta ger åtkomst till hela hyresgästen och potentiellt ger en illvillig aktör åtkomst till kunddata för alla användare.

Protokolldiagram

Följande diagram visar ROPC-flödet.

diagram som visar resursägarens flöde för lösenordsautentiseringsuppgifter

Auktoriseringsbegäran

ROPC-flödet är en enda begäran. den skickar klientidentifieringen och användarens autentiseringsuppgifter till identitetsprovidern och tar emot token i gengäld. Klienten måste begära användarens e-postadress (UPN) och lösenord innan du gör det. Omedelbart efter en lyckad begäran bör klienten på ett säkert sätt ta bort användarens autentiseringsuppgifter från minnet. Det får aldrig rädda dem.

// Line breaks and spaces are for legibility only.  This is a public client, so no secret is required.

POST {tenant}/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=user.read%20openid%20profile%20offline_access
&username=MyUsername@myTenant.com
&password=SuperS3cret
&grant_type=password
Parameter Tillstånd Beskrivning
tenant Krävs Den katalogklient som du vill logga in användaren i. Hyresgästen kan vara i GUID- eller vänligt namnformat. Parametern kan dock inte anges till common eller consumers, men kan vara inställd på organizations.
client_id Krävs Det program-ID (klient)-ID som Administrationscenter för Microsoft Entra – Appregistreringar sida som tilldelats din app.
grant_type Krävs Måste anges till password.
username Krävs Användarens e-postadress.
password Krävs Användarens lösenord.
scope Rekommenderad En blankstegsavgränsad lista över områdeneller behörigheter som appen kräver. I ett interaktivt flöde måste administratören eller användaren godkänna dessa omfång i förväg.
client_secret Ibland krävs Om din app är en offentlig klient kan client_secret eller client_assertion inte inkluderas. Om appen är en konfidentiell klient måste den inkluderas.
client_assertion Ibland krävs En annan form av client_secretsom genereras med hjälp av ett certifikat. Mer information finns i certifikatautentiseringsuppgifter.

Lyckat autentiseringssvar

I följande exempel visas ett lyckat tokensvar:

{
    "token_type": "Bearer",
    "scope": "User.Read profile openid email",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
Parameter Format Beskrivning
token_type Sträng Ställ alltid in på Bearer.
scope Strängar som separeras med mellanslag Om en åtkomsttoken returnerades visar den här parametern de omfång som åtkomsttoken är giltig för.
expires_in Int Antal sekunder som den inkluderade åtkomsttoken är giltig för.
access_token Ogenomskinlig sträng Utfärdat för -skop som begärdes.
id_token JWT Utfärdad om den ursprungliga scope-parametern innehöll openid omfång.
refresh_token Ogenomskinlig sträng Utfärdad om den ursprungliga scope-parametern inkluderade offline_access.

Du kan använda uppdateringstoken för att hämta nya åtkomsttoken och uppdateringstoken med samma flöde som beskrivs i OAuth Code-flödesdokumentationen.

Varning

Försök inte verifiera eller läsa token för något API som du inte äger, inklusive token i det här exemplet, i koden. Token för Microsoft-tjänster kan använda ett särskilt format som inte verifieras som en JWT och som även kan krypteras för användare (Microsoft-konto). Att läsa tokens är ett användbart felsöknings- och inlärningsverktyg, men ta inte beroenden på detta i din kod eller anta specifika om tokens som inte är för ett API som du kontrollerar.

Felsvar

Om användaren inte har angett rätt användarnamn eller lösenord, eller om klienten inte har fått det begärda medgivandet, misslyckas autentiseringen.

Fel Beskrivning Klientåtgärd
invalid_grant Autentiseringen misslyckades Autentiseringsuppgifterna var felaktiga eller så har klienten inte medgivande för de begärda omfången. Om omfången inte beviljas returneras ett consent_required fel. För att lösa det här felet bör klienten skicka användaren till en interaktiv prompt med hjälp av en webbvy eller webbläsare.
invalid_request Begäran har konstruerats felaktigt Beviljandetypen stöds inte i /common- eller /consumers-autentiseringskontexter. Använd /organizations eller ett klient-ID i stället.

Lära sig mer

Ett exempel på implementering av ROPC-flödet finns i .NET-konsolprogram kodexempel på GitHub.