Svenska

OAuth
klient
offentlig
konfidentiell
PKCE

Vad är skillnaden mellan offentliga och konfidentiella klienter?

Den här artikeln avslöjar skillnaderna mellan offentliga och konfidentiella klienter i OAuth, med Logto-applikationer som exempel.

Darcy Ye

Developer

2/21/2024

Sluta slösa veckor på användarautentisering

Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.

Kom igång

När du använder Logto för att skapa en applikation kommer du att märka att det finns flera olika applikationstyper att välja mellan, inklusive Single Page Application (SPA), Native App och Traditionell Web App. Intuitivt, från namnet, är det tydligt att en Native App körs på operativsystem som vanligtvis finns på enheter som telefoner. Men vad exakt är SPA och traditionell webbapplikation? Varför behöver vi skilja mellan dessa olika typer av appar? Den här artikeln kommer att avslöja svaren på dessa frågor.

Innan vi börjar, måste vi ge en kort introduktion till några koncept.

Vad är OAuth?

OAuth är en öppen standard för åtkomstdelegation, som vanligtvis används som ett sätt för internetanvändare att ge webbplatser eller applikationer åtkomst till deras information på andra webbplatser utan att tillhandahålla sina lösenord.

Under det senaste decenniet har det gradvis blivit den standardiserade auktorisationsprocessen och har blivit allmänt accepterad av de flesta företag som Google, Meta, Microsoft med flera. Den för närvarande använda versionen är OAuth 2.0.

I sammanhanget av OAuth refererar applikationen vi nämnde tidigare till som Klient. De kan göra förfrågningar om skyddade resurser, givet att de har erhållit resursägarens auktorisation (vanligtvis slutanvändare).

Offentliga klienter och konfidentiella klienter

OAuth definierar två klienttyper, baserat på deras förmåga att upprätthålla konfidentialiteten hos klientuppgifterna.

Konfidentiell klient

En klient som är kapabel att upprätthålla konfidentialiteten hos sina uppgifter (till exempel en klient implementerad på en säker server med begränsad åtkomst till klientuppgifterna) eller en som är kapabel till säker klientautentisering genom andra medel.

Offentlig klient

En klient som inte kan upprätthålla konfidentialiteten hos sina uppgifter (till exempel en klient som körs på resursägarens enhet, som en native app eller en webbaserad app) och är också oförmögen att säkert autentisera som en klient genom andra medel.

SPA, native applikation och traditionell webbapplikation

Med den ovan nämnda bakgrundskunskapen, låt oss ta en titt på vad SPA, Native App och traditionell webbapp betyder i sammanhanget av Logto, samt om de betraktas som offentliga klienter eller konfidentiella klienter.

SPA

Klientkodens sida i en SPA laddas ner från en webbserver och körs i användaragenten (som en webbläsare) hos resursägaren på deras enhet. Protokolldata och uppgifter är lätt tillgängliga (och ofta synliga) för resursägaren.

Native app

En native app installeras och körs på resursägarens enhet. Protokolldata och uppgifter är tillgängliga för resursägaren. Det antas generellt att alla klientautentiseringsuppgifter inom applikationen kan extraheras.

Traditionell webbapp

En traditionell webbapp är en klient som körs på en webbserver. Resursägaren har tillgång till klienten genom ett HTML användargränssnitt som presenteras i användaragenten på deras enhet. Klientuppgifter samt alla access tokens som utfärdas till klienten lagras på webbservern och exponeras eller tillgängliggörs inte för resursägaren.

Så, vi kan tydligt se att SPA och native app är offentliga klienter, medan traditionell webbapp är en konfidentiell klient.

Du kan finna att när du skapar en SPA eller native app i Logto, finns det ingen App-hemlighet, medan en traditionell webbapp har både ett App-ID och en App-hemlighet. Detta beror på att hemligheten hos en offentlig klient inte kan garanteras vara säker.

Hur fungerar en klient i OAuth-auktoriseringsflödet?

När du utvecklar OAuth-applikationer, är det första steget att registrera klienten hos OAuth-tjänsteleverantören. Klientregistrering innebär att tillhandahålla information om applikationen, såsom dess namn och Redirect-URI. Sedan genererar OAuth-tjänsteleverantören ett klient-ID och en klienthemlighet, som betraktas som applikationens uppgifter.

Klient-ID:et betraktas som offentlig information och delas med användaren under OAuth-processen. Det inkluderas vanligtvis i auktoriserings-URL:n och är synligt för slutanvändare.

Å andra sidan tjänar klienthemligheten som applikationens lösenord och måste hållas hemlig. Det används i OAuth-processen för att byta ut auktoriseringskoden (förutsatt att det är auktoriseringskodsflöde) för att erhålla access token. Existensen av klienthemligheter säkerställer att endast registrerade applikationer kan slutföra byten av access tokens.

Introduktion av Proof Key för Code Exchange (PKCE)

Som tidigare nämnts, kan klienthemligheterna hos offentliga klienter inte garanteras vara säkra, och angripare kan få tillgång till klientuppgifter och utge sig för att vara klienterna för att få åtkomst till skyddade resurser, vilket inte är acceptabelt i någon situation.

PKCE (Proof Key for Code Exchange) löser detta problem genom att temporärt generera en kodverifierare i början av varje auktorisationsflöde, vilket lagras lokalt och hashas för att generera en kodutmaning som skickas till auktorisationsservern. Kodverifieraren skickas igen till auktorisationsservern när access token byts ut. Auktorisationsservern verifierar att kodverifieraren och kodutmaningen matchar, vilket säkerställer att den offentliga klienten inte har utgetts.

Kodverifieraren i PKCE fungerar faktiskt som en dynamisk klienthemlighet. Dess säkerhet säkerställs av oåterkalleligheten hos hash-algoritmen.

Sammanfattning

I denna artikel diskuterade vi begreppen konfidentiella klienter och offentliga klienter i OAuth. Vi lärde oss att konfidentiella klienter har förmågan att hålla hemligheter och säkert förvara känslig information, medan offentliga klienter saknar denna förmåga. Vi undersökte exempel på de två typerna av klienter, inklusive traditionella webbapplikationer, SPA och native appar, i sammanhanget av Logtos produktpraxis.

Vi diskuterade också klientregistreringsprocessen i OAuth och rollerna för klient-ID och klienthemlighet.

Vidare fann vi att offentliga klienter möter begränsningar i att säkert förvara klienthemligheter. För att övervinna denna begränsning introducerade vi PKCE (Proof Key for Code Exchange), en OAuth-tillägg som tillåter offentliga klienter att säkert byta auktoriseringskoder utan behovet av en klienthemlighet.

Vår produkt, Logto, är en omfattande CIAM-lösning som följer bästa praxis för OAuth och OIDC-protokollen för att säkerställa säkerhet i varje steg, inklusive användningen av PKCE för att skydda säkerheten hos offentliga klienter.

Prova Logto gratis

Vad är OAuth?#

Offentliga klienter och konfidentiella klienter#

Konfidentiell klient#

Offentlig klient#

SPA, native applikation och traditionell webbapplikation#

SPA#

Native app#

Traditionell webbapp#

Hur fungerar en klient i OAuth-auktoriseringsflödet?#

Introduktion av Proof Key för Code Exchange (PKCE)#

Sammanfattning#

Vad är OAuth?#

Offentliga klienter och konfidentiella klienter#

Konfidentiell klient#

Offentlig klient#

SPA, native applikation och traditionell webbapplikation#

SPA#

Native app#

Traditionell webbapp#

Hur fungerar en klient i OAuth-auktoriseringsflödet?#

Introduktion av Proof Key för Code Exchange (PKCE)#

Sammanfattning#

Vad är OAuth?

Offentliga klienter och konfidentiella klienter

Konfidentiell klient

Offentlig klient

SPA, native applikation och traditionell webbapplikation

SPA

Native app

Traditionell webbapp

Hur fungerar en klient i OAuth-auktoriseringsflödet?

Introduktion av Proof Key för Code Exchange (PKCE)

Sammanfattning

Vad är OAuth?

Offentliga klienter och konfidentiella klienter

Konfidentiell klient

Offentlig klient

SPA, native applikation och traditionell webbapplikation

SPA

Native app

Traditionell webbapp

Hur fungerar en klient i OAuth-auktoriseringsflödet?

Introduktion av Proof Key för Code Exchange (PKCE)

Sammanfattning