Microsofts identitetsplattform och autentiseringsuppgifter för OAuth 2.0-resursägare

den Microsofts identitetsplattform stöder OAuth 2.0 Resource Owner Password Credentials (ROPC) beviljande, vilket gör att ett program kan logga in användaren genom att direkt hantera sina lösenord. I den här artikeln beskrivs hur du kan programmera direkt mot protokollet i ditt program. När det är möjligt rekommenderar vi att du använder de Microsoft Authentication Libraries (MSAL) som stöds i stället för att hämta token och anropa skyddade webb-API:er. Ta också en titt på exempelapparna som använder MSAL.

Varning

Microsoft rekommenderar att du inte använder ROPC-flödet. 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 andra säkrare flöden inte är livskraftiga.

Viktigt!

• Microsofts identitetsplattform stöder endast ROPC-beviljandet i 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 organizations slutpunkten.
• Personliga konton som bjuds in till en Microsoft Entra-klientorganisation 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 i programmet blockeras de i stället.
• ROPC stöds inte i hybrididentitetsfederationsscenarier (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 inte testa användarnamnet och lösenordet mot identitetsprovidern. Autentisering via direktströmning stöds dock med ROPC.
• Ett undantag till ett hybrididentitetsfederationsscenario skulle vara följande: Principen För identifiering av hemsfär med AllowCloudPasswordValidation inställd på TRUE gör det möjligt för ROPC-flödet att fungera för federerade användare när ett lokalt lösenord synkroniseras till molnet. Mer information finns i Aktivera direkt ROPC-autentisering för federerade användare för äldre appar.
• Lösenord med inledande eller avslutande blanksteg stöds inte av ROPC-flödet.

Protokolldiagram

Följande diagram visar ROPC-flödet.

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	Villkor	beskrivning
tenant	Obligatoriskt	Den katalogklient som du vill logga in användaren i. Klientorganisationen kan vara i GUID- eller eget namnformat. Parametern kan dock inte anges till common eller consumers, men kan vara inställd på organizations.
client_id	Obligatoriskt	Det program-ID (klient)-ID som administrationscentret för Microsoft Entra – Appregistreringar sida som tilldelats din app.
grant_type	Obligatoriskt	Måste anges till password.
username	Obligatoriskt	Användarens e-postadress.
password	Obligatoriskt	Användarens lösenord.
scope	Rekommenderat	En utrymmesavgränsad lista över omfång eller 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 client_secret kan eller client_assertion inte kan inkluderas. Om appen är en konfidentiell klient måste den inkluderas.
client_assertion	Ibland krävs	En annan form av , som genereras med hjälp av client_secretett certifikat. Mer information finns i autentiseringsuppgifter för certifikat.

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	String	Ange alltid till Bearer.
scope	Blankstegsavgränsade strängar	Om en åtkomsttoken returnerades visar den här parametern de omfång som åtkomsttoken är giltig för.
expires_in	heltal	Antal sekunder som den inkluderade åtkomsttoken är giltig för.
access_token	Ogenomskinlig sträng	Utfärdat för de omfång som begärdes .
id_token	JWT	Utfärdad om den ursprungliga scope parametern inkluderade omfånget openid .
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 konsumentanvändare (Microsoft-konto). Läs token är ett användbart felsöknings- och inlärningsverktyg, men använd inte beroenden för detta i koden eller anta detaljer om token 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 autentiseringskontexterna /common eller /consumers . Använd /organizations eller ett klient-ID i stället.

Läs mer

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