Wat zijn de verschillen tussen publieke en vertrouwelijke clients?

Wanneer je Logto gebruikt om een applicatie te maken, zul je merken dat er verschillende applicatietypes zijn om uit te kiezen, waaronder Single Page Application (SPA), Native App en Traditionele Webapp. Intuïtief is het vanuit de naam duidelijk dat een Native App draait op besturingssystemen die vaak op apparaten zoals telefoons worden gevonden. Maar wat zijn precies SPA en Traditionele Webapp? Waarom moeten we onderscheid maken tussen deze verschillende soorten apps? Dit artikel onthult de antwoorden op deze vragen.

Voordat we beginnen, moeten we een korte introductie geven over enkele concepten.

Wat is OAuth?#

OAuth is een open standaard voor toegangsdelegatie, die doorgaans wordt gebruikt als een manier voor internetgebruikers om websites of applicaties toegang te verlenen tot hun informatie op andere websites zonder hun wachtwoorden te verstrekken.

In het afgelopen decennium is het geleidelijk de standaard-autorisatieprocedure geworden en is breed geaccepteerd door de meeste bedrijven zoals Google, Meta, Microsoft en andere. De momenteel gebruikte versie is OAuth 2.0.

In de context van OAuth wordt de applicatie die we eerder noemden een Client genoemd. Ze kunnen verzoeken indienen voor beveiligde bronnen, mits ze de autorisatie van de resource-eigenaar (meestal eindgebruikers) hebben verkregen.

Publieke clients en vertrouwelijke clients#

OAuth definieert twee cliënttypen, gebaseerd op hun vermogen om de vertrouwelijkheid van de cliëntreferenties te handhaven.

Vertrouwelijke client#

Een client die in staat is de vertrouwelijkheid van zijn referenties te behouden (bijvoorbeeld een client geïmplementeerd op een beveiligde server met beperkte toegang tot de clientreferenties) of een die in staat is tot veilige clientauthenticatie via andere middelen.

Publieke client#

Een client die niet in staat is de vertrouwelijkheid van zijn referenties te behouden (bijvoorbeeld een client die draait op het apparaat van de resource-eigenaar, zoals een native app of een webgebaseerde app) en ook niet in staat is veilig te authenticeren als een client via andere middelen.

SPA, native applicatie en traditionele webapplicatie#

Met de bovengenoemde achtergrondkennis, laten we eens kijken wat SPA, Native App en traditionele webapp betekenen in de context van Logto, evenals of ze als publieke clients of vertrouwelijke clients worden beschouwd.

SPA#

De client-side code van een SPA wordt gedownload van een webserver en uitgevoerd in de gebruikeragent (zoals een webbrowser) van de resource-eigenaar op hun apparaat. De protocolgegevens en referenties zijn gemakkelijk toegankelijk (en vaak zichtbaar) voor de resource-eigenaar.

Native app#

Een native app is geïnstalleerd en uitgevoerd op het apparaat van de resource-eigenaar. De protocolgegevens en referenties zijn toegankelijk voor de resource-eigenaar. Over het algemeen wordt aangenomen dat eventuele cliëntauthenticatie die in de applicatie is opgenomen, kan worden geëxtraheerd.

Traditionele webapp#

Een traditionele webapp is een client die draait op een webserver. De resource-eigenaar heeft toegang tot de client via een HTML-gebruikersinterface gepresenteerd in de gebruikeragent op hun apparaat. De cliëntreferenties evenals eventuele toegangstokens die aan de client zijn uitgegeven, worden opgeslagen op de webserver en zijn niet blootgesteld of toegankelijk voor de resource-eigenaar.

Dus we kunnen duidelijk zien dat SPA en native app publieke clients zijn, terwijl de traditionele webapp een vertrouwelijke client is.

Je zult merken dat wanneer je een SPA of native app maakt in Logto, er geen App-geheim is, terwijl een traditionele webapp zowel een App-ID als een App-geheim heeft. Dit is omdat de geheimhouding van een publieke client niet kan worden gegarandeerd.

Hoe werkt een client in de OAuth-autorisatiestroom?#

Bij het ontwikkelen van OAuth-toepassingen is de eerste stap om de client te registreren bij de OAuth-serviceprovider. Cliëntregistratie omvat het verstrekken van details over de applicatie, zoals de naam en de Redirect-URI. Vervolgens genereert de OAuth-serviceprovider een client-ID en een cliëntgeheim, die als de referenties van de applicatie worden beschouwd.

De client-ID wordt beschouwd als openbare informatie en wordt gedeeld met de gebruiker tijdens het OAuth-proces. Het is meestal opgenomen in de autorisatie-URL en zichtbaar voor eindgebruikers.

Aan de andere kant dient het clientgeheim als het wachtwoord voor de applicatie en moet het geheim worden gehouden. Het wordt gebruikt in het OAuth-proces om de autorisatiecode (ervan uitgaande dat het de autorisatiecodeflow is) uit te wisselen voor de toegangstoken. Het bestaan van cliëntgeheimen zorgt ervoor dat alleen geregistreerde applicaties de uitwisseling van toegangstokens kunnen voltooien.

Introductie van Proof Key for Code Exchange (PKCE)#

Zoals eerder vermeld, kunnen de clientgeheimen van publieke clients niet als veilig worden gegarandeerd, en aanvallers kunnen clientreferenties verkrijgen en clients imiteren om toegang te krijgen tot beveiligde resources, wat in geen enkele situatie acceptabel is.

PKCE (Proof Key for Code Exchange) lost dit probleem op door tijdelijk een codeverifier te genereren aan het begin van elke autorisatiestroom, die lokaal wordt opgeslagen en gehasht om een code challenge te genereren die naar de autorisatieserver wordt gestuurd. De codeverifier wordt opnieuw naar de autorisatieserver gestuurd bij het uitwisselen van de toegangstoken. De autorisatieserver controleert of de codeverifier en code challenge overeenkomen, wat ervoor zorgt dat de publieke client niet is geïmiteerd.

De codeverifier in PKCE fungeert eigenlijk als een dynamisch cliëntgeheim. De veiligheid ervan wordt gewaarborgd door de onomkeerbaarheid van het hash-algoritme.

Samenvatting#

In dit artikel hebben we de concepten van vertrouwelijke clients en publieke clients in OAuth besproken. We hebben geleerd dat vertrouwelijke clients het vermogen hebben om geheimen te bewaren en gevoelige informatie veilig op te slaan, terwijl publieke clients dit vermogen niet hebben. We hebben voorbeelden onderzocht van de twee typen clients, waaronder traditionele webapps, SPA en native apps, in de context van Logto's productpraktijken.

We hebben ook het registratiproces van clients in OAuth besproken en de rollen van client-ID en cliëntgeheim.

Bovendien hebben we vastgesteld dat publieke clients beperkingen hebben bij het veilig opslaan van klantgeheimen. Om deze beperking te overwinnen, hebben we PKCE (Proof Key for Code Exchange) geïntroduceerd, een OAuth-uitbreiding die publieke clients in staat stelt om autorisatiecodes veilig uit te wisselen zonder de noodzaak van een cliëntgeheim.

Ons product, Logto, is een uitgebreide CIAM-oplossing die de best practices van de OAuth- en OIDC-protocollen volgt om veiligheid in elke fase te waarborgen, inclusief de adoptie van het gebruik van PKCE om de veiligheid van publieke clients te beschermen.