Waarom je het Resource Owner Password Credentials (ROPC) grant type moet afschaffen

Inleiding#

Het Resource Owner Password Credentials (ROPC) grant type, ook wel het wachtwoordgrant type genoemd, is een OAuth 2.0 flow die een applicatie in staat stelt om een gebruikersnaam en wachtwoord van een gebruiker om te wisselen voor een toegangstoken. Het werd voor het eerst geïntroduceerd in de OAuth 2.0-specificatie als een manier om verouderde applicaties te ondersteunen, zoals HTTP basic authenticatie of verouderde native applicaties die de meer beveiligde OAuth-tokenized flows niet konden gebruiken.

Echter, het ROPC grant type brengt verschillende beveiligingsrisico's met zich mee en is als een MAG NIET worden gebruikt gemarkeerd in de OAuth 2.0 veiligheid beste praktijken.

Recentelijk hebben we verschillende vragen ontvangen van onze klanten die richtlijnen of ondersteuning vragen voor het implementeren van het ROPC grant type. In dit artikel zullen we uitleggen waarom je het ROPC grant type moet vermijden, vooral voor je nieuwe applicaties.

ROPC grant type vs. autorisatiecode flow#

Hoe het ROPC grant type werkt#

Het ROPC grant type is een eenvoudige flow die de gebruikersnaam en het wachtwoord van de gebruiker inwisselt voor een toegangstoken. De clientapplicatie verzamelt direct de inloggegevens van de gebruiker en stuurt ze direct naar de autorisatieserver. De autorisatieserver valideert vervolgens de inloggegevens en geeft een toegangstoken uit aan de client.

Hoe de autorisatiecode flow werkt#

Daarentegen is de autorisatiecode flow de aanbevolen OAuth 2.0 flow voor webapplicaties. Het omvat meerdere stappen en omleidingen tussen de clientapplicatie, de autorisatieserver, en de browser van de gebruiker. De autorisatiecode flow is veiliger omdat het de gebruikersinloggegevens niet blootstelt aan de clientapplicatie.

Het belangrijkste verschil tussen het ROPC grant type en de autorisatiecode flow is dat ROPC de gebruikersinloggegevens blootstelt aan de clientapplicatie, terwijl de autorisatiecode flow dat niet doet. Gebruikersinloggegevens moeten vertrouwelijk worden bewaard binnen de autorisatieserver. Telkens wanneer een clientapplicatie een resource namens de gebruiker aanvraagt, moet deze de gebruiker doorverwijzen naar de autorisatieserver om de clientapplicatie te authenticeren en autoriseren. Dit houdt een minimale hoeveelheid autorisatiegegevens aan de kant van de clientapplicatie.

Beveiligingsrisico's van het ROPC grant type#

1. Blootstelling van gebruikersinloggegevens#

Zoals eerder vermeld, stelt het ROPC grant type de inloggegevens van de gebruiker bloot aan de clientapplicatie. Dit is een aanzienlijk beveiligingsrisico omdat de clientapplicatie de gebruikersinloggegevens kan opslaan of loggen, en opnieuw kan autoriseren zonder het bewustzijn van de gebruiker.

Vooral voor een openbare clientapplicatie zoals een mobiele applicatie of een single-page applicatie, kan de clientapplicatie gemakkelijk worden geïnjecteerd of teruggeprogrammeerd om de inloggegevens van de gebruiker te extraheren. Noch een mobiele applicatie, noch een single-page applicatie die op de browser van de gebruiker draait, kan vertrouwelijkheden bewaren. Dus, ze kunnen de gebruiker niet authentiseren zonder de inloggegevens van de gebruiker bloot te stellen.

Zelfs als de resource-eigenaar een vertrouwde relatie heeft met de clientapplicatie, speelt de clientapplicatie een man-in-the-middle-rol in het hele authenticatieproces, en kan het worden gecompromitteerd door een andere kwaadwillende acteur. De kwaadwillende acteur kan de inloggegevens van de gebruiker stelen en de gebruiker nabootsen om toegang te krijgen tot de resources van de gebruiker.

Er zijn meerdere manieren om de inloggegevens van de gebruiker te stelen, gebaseerd op de veiligheidspositie van de clientapplicatie, zoals keyloggers, phishing-aanvallen of malware. Even niet te praten over de clientinloggegevens die over het netwerk worden verzonden bij elke autorisatieaanvraag. Dit verhoogt verder het risico van onderschepping van inloggegevens.

Stel je voor dat je meerdere applicaties hebt die het ROPC grant type gebruiken, het potentiële risico van blootstelling van inloggegevens wordt vermenigvuldigd.

2. ROPC ondersteunt geen gebruikersinstemming#

Het ROPC grant type ondersteunt geen gebruikersinstemming. Wanneer de clientapplicatie de inloggegevens van de gebruiker direct verzamelt, heeft de gebruiker niet de mogelijkheid om de toegang van de clientapplicatie tot hun resources te beoordelen en goed te keuren. Dit is een schending van de privacy en het vertrouwen van de gebruiker.

Gebruikers zouden het recht moeten hebben om te beslissen welke clientapplicatie toegang kan krijgen tot hun resources en voor hoelang. Vooral voor applicaties van derden is een gebruikersinstemmingsmechanisme essentieel om de gegevens van de resource-eigenaar te beschermen en is het essentieel om te voldoen aan regelgeving voor gegevensbescherming zoals GDPR.

3. ROPC ondersteunt geen multi-factor authenticatie#

Multi-factor authenticatie (MFA) is een beveiligingsimplementatie die vereist dat de gebruiker twee of meer verificatiefactoren levert om toegang te krijgen tot hun resources. Het voegt een extra beveiligingslaag toe aan het authenticatieproces. Het ROPC grant type ondersteunt geen MFA. In plaats daarvan beperkt het het authenticatieproces tot een enkele factor, en het tokenverzoek is alleen gebaseerd op de inloggegevens van de gebruiker. Het is onmogelijk om challenge-gebaseerde authenticatiemechanismen zoals SMS OTP, e-mail OTP of WebAuthn te implementeren met het ROPC grant type.

ROPC is niet compatibel met moderne applicaties#

Het ROPC grant type was ontworpen om legacy applicaties te ondersteunen die geen moderne IAM-systemen zoals Single Sign-On (SSO) of gefedereerde identiteiten kunnen ondersteunen.

1. ROPC is niet compatibel met SSO#

Single Sign-On (SSO) is een moderne authenticatiearchitectuur die gebruikers in staat stelt om één keer in te loggen en toegang te krijgen tot meerdere applicaties zonder moeite.

Een gecentraliseerde IdP speelt een cruciale rol in de SSO-architectuur. Het beheert de authenticatiesessie van de gebruiker en geeft tokens uit aan de clientapplicaties. De clientapplicaties hoeven de inloggegevens van de gebruiker niet direct te verzamelen, en de inloggegevens van de gebruiker worden vertrouwelijk bewaard binnen de IdP.

Het ROPC grant type ondersteunt SSO niet. Het vereist dat de clientapplicatie de inloggegevens van de gebruiker direct verzamelt, wat de SSO-architectuur doorbreekt. Het is niet compatibel met moderne SSO-systemen zoals OpenID Connect (OIDC) of SAML.

2. ROPC is niet compatibel met gefedereerde identiteiten#

Net als de SSO-architectuur staan gefedereerde identiteiten gebruikers toe om hun bestaande identiteit te gebruiken om toegang te krijgen tot meerdere applicaties van derden. Een gebruiker kan meerdere sociale accounts zoals Google, Facebook of Twitter koppelen aan een gecentraliseerde IdP, en deze sociale accounts gebruiken om te authenticeren met de clientapplicaties. Alle gefedereerde identiteiten worden beheerd door de IdP, en de clientapplicaties zijn zich niet bewust van de authenticatiedetails van de gebruiker onder de motorkap.

Het ROPC grant type vereist echter dat de clientapplicatie de inloggegevens van de gebruiker direct verzamelt. Het beperkt de mogelijkheden van de clientapplicatie om gefedereerde identiteiten te ondersteunen en stelt de identiteitsgegevens van de gebruiker bloot aan de clientapplicatie.

Conclusie#

Het Resource Owner Password Credentials (ROPC) grant type is een verouderde OAuth 2.0 flow die aanzienlijke beveiligingsrisico's met zich meebrengt en moet worden afgeschaft. Het stelt de inloggegevens van de gebruiker bloot aan de clientapplicatie en ondersteunt geen moderne beveiligingsmechanismen zoals MFA of SSO. We raden sterk aan het gebruik van het ROPC grant type voor je applicaties te vermijden. Als je legacy authenticatiesystemen hebt die afhankelijk zijn van het ROPC grant type, overweeg dan om over te stappen naar veiliger OAuth 2.0 flows zoals de autorisatiecode flow of de clientinloggegevens flow.

Neem contact met ons op als je hulp nodig hebt bij het integreren van een veilige gebruikersauthenticatie- en autorisatiedienst in je applicaties, of bij het migreren van het verouderde wachtwoord gebaseerde authenticatiesysteem naar een veiligere OAuth 2.0 flow. We zijn hier om je te helpen bij het bouwen van veilige en moderne applicaties.