Nederlands

oauth
impliciete stroom
autorisatiecode
PKCE

Impliciete stroom vs. Autorisatiecode stroom: Waarom de impliciete stroom dood is?

Waarom is er een "Autorisatiecode stroom" in OAuth 2.0 als we al de "Impliciete stroom" hebben? Laten we dieper ingaan op de details van deze twee soorten toestemming en ontdekken waarom je de impliciete stroom moet vermijden.

Darcy Ye

Developer

1/3/2024

Stop met weken verspillen aan gebruikersauthenticatie

Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.

Aan de slag

De Autorisatiecode stroom en Impliciete stroom zijn twee van de meest gebruikte toestemmingstypes in OAuth 2.0, die veilige en efficiënte gebruikersautorisatie voor webapplicaties mogelijk maken. Beide stromen implementeren een autorisatieproces dat gebruikers toestaat toegang te verlenen aan applicaties zonder hun inloggegevens direct bloot te stellen. De Impliciete stroom werd oorspronkelijk ontwikkeld om browserbeperkingen aan te pakken, maar met de opkomst van moderne webtechnologieën is de Autorisatiecode stroom de voorkeur geworden van veel ontwikkelaars vanwege zijn verbeterde beveiligingsfuncties.

In dit artikel zullen we de verschillen tussen deze twee soorten toestemming verkennen en uitleggen waarom je de Impliciete stroom moet vermijden ten gunste van de Autorisatiecode stroom.

Wat is OAuth 2.0?

Voordat we ingaan op de details van deze twee soorten toestemming, laten we eerst begrijpen wat OAuth 2.0 is en waarom het essentieel is voor moderne webapplicaties.

Wanneer mensen praten over OAuth, verwijzen we meestal naar OAuth 2.0, bekend als "Open Authorization", een gevestigd protocol dat websites of applicaties in staat stelt om bronnen van andere webservices namens een gebruiker te gebruiken. Het volgde OAuth 1.0 op in 2012 en is sindsdien de breed geaccepteerde standaard voor digitale autorisatie geworden. OAuth 2.0 is ontworpen om gecontroleerde toegang aan gebruikers te bieden, zodat clientapplicaties specifieke permissies hebben om te communiceren met bronnen die de gebruiker vertegenwoordigen, allemaal zonder de inloggegevens van de gebruiker te onthullen.

Hoewel het voornamelijk in webomgevingen wordt gebruikt, strekt het framework van OAuth 2.0 zich ook uit tot verschillende clientvormen. Dit omvat browsergebaseerde apps, server-side webapplicaties, native of mobiele applicaties, en zelfs verbonden apparaten, waarin de benadering voor het beheren van gedelegeerde toegang tussen deze platforms wordt beschreven. Het introduceert het concept van "toestemmingstypes" om het autorisatieproces te definiëren tussen de clientapplicatie, de gebruiker en de autorisatieserver. Deze toestemmingstypes worden gebruikt om te bepalen hoe de clientapplicatie een toegangstoken kan verkrijgen om toegang te krijgen tot de bronnen van de gebruiker. De meest voorkomende toestemmingstypes in OAuth 2.0 zijn:

Autorisatiecode: Ideaal voor alle soorten applicaties, vooral server-side webapplicaties, waarin de clientapplicatie een autorisatiecode kan inwisselen voor een toegangstoken en tokens veilig kan beheren.
Impliciet: Een vereenvoudigde stroom, ontworpen voor browsergebaseerde applicaties, zonder een veilig servercomponent. Het werd gecreëerd om snel tokens aan de clientapplicaties te leveren. Maar het is nu grotendeels verouderd vanwege beveiligingsproblemen.
Resource owner password credentials: Dit type stelt de clientapplicatie in staat om directe aanvraag en ontvangst van een toegangstoken door het indienen van de inloggegevens van de gebruiker (gebruikersnaam en wachtwoord). Omdat de clientapplicatie directe toegang heeft tot de inloggegevens van de gebruiker, wordt dit toestemmingstype ook als verouderd beschouwd en moet in alle omstandigheden worden vermeden.
Client credentials: Gebruikt voor machine-to-machine communicatie waarbij de applicatie zelf de client is. Het omvat het authenticeren van de applicatie bij de autorisatieserver en het aanvragen van een toegangstoken om toegang te krijgen tot zijn eigen bronnen of die van een andere service.

Wat is de impliciete stroom?

De impliciete stroom is een vereenvoudigde OAuth 2.0 stroom waarbij het toegangstoken rechtstreeks aan de client wordt geretourneerd in de redirect URI, zonder een extra stap om een autorisatiecode in te wisselen voor een token. Het was oorspronkelijk ontworpen voor webapplicaties die geen server-side verzoeken konden maken naar het token eindpunt vanwege browserbeperkingen.

Hoe werkt de impliciete stroom?

De gebruiker klikt op een knop of link in de clientapplicatie om het authenticatieproces te starten.
De clientapplicatie leidt de gebruiker om naar de autorisatieserver om te authenticeren, inclusief het gewenste toegangsomvang.
De autorisatieserver vraagt gebruikers om in te loggen en toestemming te geven aan de clientapplicatie.
Na succesvolle authenticatie en autorisatie, leidt de autorisatieserver de browser van de gebruiker terug naar de gespecificeerde redirect URI van de client, met het toegangstoken inbegrepen in de URL-fragment.
De clientapplicatie haalt het toegangstoken uit de URL-fragment en gebruikt het om toegang te krijgen tot de bronnen van de gebruiker op de resourceserver.

Beveiligingsrisico's met de impliciete stroom

De impliciete stroom heeft verschillende beveiligingskwetsbaarheden:

Token blootstelling: Het toegangstoken wordt direct aan de client geretourneerd in de URL-fragment, wat gemakkelijk kan worden onderschept door kwaadwillende partijen. Dit stelt het toegangstoken bloot aan potentieel diefstal en misbruik.
CSRF aanvallen: De impliciete stroom is vatbaar voor Cross-Site Request Forgery (CSRF) aanvallen, waarbij kwaadaardige websites gebruikers kunnen misleiden om ongeoorloofde toegang te verlenen tot hun accounts.

Vanwege deze beveiligingsproblemen wordt de impliciete stroom niet langer aanbevolen voor moderne webapplicaties. In plaats daarvan is de autorisatiecode stroom met PKCE (Proof Key for Code Exchange) de voorkeursoptie voor veilige gebruikersautorisatie.

Wat is de autorisatiecode stroom?

De autorisatiecode stroom daarentegen is een veiliger OAuth 2.0 stroom die het autorisatieproces in twee stappen opsplitst: de clientapplicatie verkrijgt eerst een autorisatiecode van de autorisatieserver, en wisselt vervolgens de code in voor een toegangstoken. Deze stroom was aanvankelijk ontworpen voor server-side webapplicaties die client-inloggegevens veilig kunnen opslaan en toegangstokens kunnen beheren. Met de introductie van de PKCE-uitbreiding kan de autorisatiecode stroom nu ook worden gebruikt in browsergebaseerde applicaties.

Hoe werkt de autorisatiecode stroom voor privéclients met server-side component?

De gebruiker klikt op een knop of link in de clientapplicatie om het authenticatieproces te starten.
De clientapplicatie leidt de gebruiker om naar de autorisatieserver om te authenticeren met de gewenste toegangsomvang.
De autorisatieserver vraagt gebruikers om in te loggen en toestemming te geven aan de clientapplicatie.
Na succesvolle authenticatie en autorisatie, retourneert de autorisatieserver een autorisatiecode aan de client.
De clientapplicatie wisselt de autorisatiecode veilig in voor een toegangstoken door een server-to-server verzoek te maken naar het token eindpunt met behulp van zijn client-inloggegevens.
De autorisatieserver valideert de autorisatiecode en de client-inloggegevens en retourneert een toegangstoken aan de client.
De clientapplicatie gebruikt het toegangstoken om toegang te krijgen tot de bronnen van de gebruiker op de resourceserver.

Hoe werkt de autorisatiecode stroom voor publieke clients met PKCE?

De gebruiker klikt op een knop of link in de clientapplicatie om het authenticatieproces te starten.
De clientapplicatie genereert een code verifier en een code challenge.
De clientapplicatie leidt de gebruiker om naar de autorisatieserver om te authenticeren met de code challenge.
De autorisatieserver slaat de code challenge op voor latere verificatie.
De gebruiker authenticeert en keurt toegang tot de clientapplicatie goed.
De autorisatieserver retourneert een autorisatiecode aan de client.
De clientapplicatie wisselt de autorisatiecode in voor een toegangstoken door een server-to-server verzoek te maken naar het token eindpunt met de code verifier.
De autorisatieserver valideert de autorisatiecode en de code verifier tegen de opgeslagen code challenge.
De autorisatieserver retourneert een toegangstoken aan de client.
De clientapplicatie gebruikt het toegangstoken om toegang te krijgen tot de bronnen van de gebruiker op de resourceserver.

Leer meer over de PKCE stroom.