Varför du bör avveckla Resource Owner Password Credentials (ROPC) grant-typ

Introduktion#

Resource Owner Password Credentials (ROPC) grant-typ, även känd som lösenordsgrant-typ, är ett OAuth 2.0-flöde som tillåter en applikation att utbyta en användares användarnamn och lösenord mot en åtkomsttoken. Det introducerades först i OAuth 2.0-specifikationen som ett sätt att stödja äldre applikationer som HTTP grundläggande autentisering eller äldre inbyggda applikationer som inte kunde använda de mer säkra OAuth-tokeniserade flödena.

ROPC grant-typen utgör dock flera säkerhetsrisker och har markerats som en MÅSTE INTE användas i OAuth 2.0 säkerhetsbästa praxis.

På senare tid har vi fått flera frågor från våra kunder som begär vägledning eller support för att implementera ROPC grant-typ. I detta inlägg kommer vi att förklara varför du bör undvika att använda ROPC grant-typ, speciellt för dina nya applikationer.

ROPC grant-typ vs. auktorisationskodflöde#

Hur ROPC grant-typ fungerar#

ROPC grant-typ är ett enkelt flöde som utbyter användarens användarnamn och lösenord mot en åtkomsttoken. Klientapplikationen samlar in användarens autentiseringsuppgifter direkt och skickar dem direkt till auktorisationsservern. Auktorisationsservern validerar sedan autentiseringsuppgifterna och utfärdar en åtkomsttoken till klienten.

Hur auktorisationskodflödet fungerar#

I kontrast är auktorisationskodflödet det rekommenderade OAuth 2.0-flödet för webbapplikationer. Det involverar flera steg och omdirigeringar mellan klientapplikationen, auktorisationsservern och användarens webbläsare. Auktorisationskodflödet är säkrare eftersom det inte exponerar användarens autentiseringsuppgifter för klientapplikationen.

De främsta skillnaderna mellan ROPC grant-typ och auktorisationskodflöde är att ROPC exponerar användarens autentiseringsuppgifter för klientapplikationen, medan auktorisationskodflödet inte gör det. Användarens autentiseringsuppgifter bör hållas konfidentiellt inom auktorisationsservern. När en klientapplikation begär en resurs å användarens vägnar, bör den omdirigera användaren till auktorisationsservern för att autentisera och auktorisera klientapplikationen. Det håller ett minimalt antal auktorisationsdata på klientapplikationssidan.

Säkerhetsrisker med ROPC grant-typ#

1. Exponering av användarens autentiseringsuppgifter#

Som vi nämnde tidigare, exponerar ROPC grant-typ användarens autentiseringsuppgifter för klientapplikationen. Detta är en betydande säkerhetsrisk eftersom klientapplikationen kan lagra eller logga användarens autentiseringsuppgifter och omauktorisera utan användarens medvetenhet.

Speciellt för en publik klientapplikation som en mobilapplikation eller en en-sidig applikation, kan klientapplikationen enkelt injiceras eller omvänt konstrueras för att extrahera användarens autentiseringsuppgifter. Varken en mobilapplikation eller en en-sidig applikation som körs i användarens webbläsare kan hålla hemligheter konfidentiellt. Därmed kan de inte autentisera användaren utan att exponera användarens autentiseringsuppgifter.

Även om resursägaren har en betrodd relation med klientapplikationen, spelar klientapplikationen en man-i-mitten-roll i hela autentiseringsprocessen, den kan komprometteras av en annan illvillig aktör. Den illvilliga aktören kan stjäla användarens autentiseringsuppgifter och låtsas vara användaren för att få tillgång till användarens resurser.

Det finns flera sätt att stjäla användarens autentiseringsuppgifter, beroende på klientapplikationens säkerhetsposition, som tangentloggare, nätfiskeattacker eller skadeprogram. Inte att nämna att klientautentiseringsuppgifterna överförs över nätverket vid varje auktorisationsförfrågan. Det ökar ytterligare risken för avlyssning av autentiseringsuppgifter.

Föreställ dig om du har flera applikationer som använder ROPC grant-typ, den potentiella risken för exponering av autentiseringsuppgifter multipliceras.

2. ROPC stöder inte användarsamtycke#

ROPC grant-typ stöder inte användarsamtycke. När klientapplikationen samlar in användarens autentiseringsuppgifter direkt, har användaren inte möjlighet att granska och godkänna klientapplikationens åtkomst till deras resurser. Detta är ett brott mot användarens integritet och förtroende.

Användare bör ha rätt att bestämma vilken klientapplikation som kan komma åt deras resurser och hur länge. Speciellt för tredjepartsapplikationer är en användarsamtyckesmekanism avgörande för att skydda resursägarens data och det är avgörande för att följa dataskyddsförordningar som GDPR.

3. ROPC stöder inte multifaktorautentisering#

Multifaktorautentisering (MFA) är en säkerhetsimplementering som kräver att användaren tillhandahåller två eller fler verifieringsfaktorer för att få tillgång till sina resurser. Det lägger till ett extra lager av säkerhet till autentiseringsprocessen. ROPC grant-typ stöder inte MFA. Istället begränsar det autentiseringsprocessen till en enda faktor, och tokenförfrågan baseras enbart på användarens autentiseringsuppgifter. Det är omöjligt att implementera utmaningsbaserade autentiseringsmekanismer som SMS OTP, e-post OTP eller WebAuthn med ROPC grant-typ.

ROPC är inte kompatibel med moderna applikationer#

ROPC grant-typ var utformad för att stödja äldre applikationer som inte kan stödja moderna IAM-system, Single Sign-On (SSO) eller federerade identiteter.

1. ROPC är inte kompatibel med SSO#

Single Sign-On (SSO) är en modern autentiseringsarkitektur som tillåter användare att logga in en gång och få tillgång till flera applikationer utan problem.

En central IdP spelar en avgörande roll i SSO-arkitekturen. Den hanterar användarens autentiseringssession och utfärdar tokens till klientapplikationerna. Klientapplikationerna behöver inte samla in användarens autentiseringsuppgifter direkt, och användarens autentiseringsuppgifter hålls konfidentiellt inom IdP.

ROPC grant-typ stöder inte SSO. Det kräver att klientapplikationen samlar in användarens autentiseringsuppgifter direkt, vilket bryter SSO-arkitekturen. Det är inte kompatibelt med moderna SSO-system som OpenID Connect (OIDC) eller SAML.

2. ROPC är inte kompatibel med federerade identiteter#

Liknande SSO-arkitekturen tillåter federerade identiteter användare att använda sin befintliga identitet för att få tillgång till flera tredjepartsapplikationer. En användare kan länka flera sociala konton som Google, Facebook eller Twitter till en central IdP och använda dessa sociala konton för att autentisera med klientapplikationerna. Alla federerade identiteter hanteras av IdP, och klientapplikationerna är inte medvetna om användarens autentiseringsdetaljer under huven.

ROPC grant-typ, istället, kräver att klientapplikationen samlar in användarens autentiseringsuppgifter direkt. Det begränsar klientapplikationens förmåga att stödja federerade identiteter och exponerar användarens identitetsdata för klientapplikationen.

Slutsats#

Resource Owner Password Credentials (ROPC) grant-typ är ett föråldrat OAuth 2.0-flöde som medför betydande säkerhetsrisker och bör avvecklas. Det exponerar användarens autentiseringsuppgifter för klientapplikationen och stöder inte moderna säkerhetsmekanismer som MFA eller SSO. Vi rekommenderar starkt att undvika att använda ROPC grant-typ för dina applikationer. Om du har äldre autentiseringssystem som förlitar sig på ROPC grant-typ, överväg att migrera till mer säkra OAuth 2.0-flöden som auktorisationskodflödet eller klient-authentiseringsflödet.

Kontakta oss om du behöver hjälp med att integrera säker användarautentisering och auktorisationstjänst i dina applikationer, eller migrera från det äldre lösenordsbaserade autentiseringssystemet till ett mer säkert OAuth 2.0-flöde. Vi är här för att hjälpa dig bygga säkra och moderna applikationer.