OpenID Connect (OIDC) protokollet har blivit en allmänt antagen standard för identitetshantering. Men förstår du verkligen rollerna och attributen för dessa token?
OpenID Connect Protocol, även känt som OIDC, har blivit en allmänt antagen standard för att tillhandahålla en grundläggande ram för identitetshantering. Det är ett autentiseringslager byggt ovanpå det välkända OAuth 2.0 protokollet. Medan OAuth 2.0 enbart är för resursauktorisation, är OIDC protokollet som standardiserar och förstärker klientautentisering, med hjälp av den nyintroducerade ID-token.
Vänta... Du kanske har hört talas om åtkomsttoken och uppfräscha token i OAuth-eran, och nu kommer det nya konceptet i OIDC? Förstår du verkligen skillnaderna mellan dessa token?
Låt oss börja med ett praktiskt scenario.
Föreställ dig att du utvecklar en typisk klient-server-applikation, och de kommunicerar med varandra via RESTful API:er. Du vill hålla de flesta av dina API:er privata, endast tillåter auktoriserade klienter att få tillgång. Du kommer att behöva en mekanism för att autentisera klienten och auktorisera API-begärandena till din server.
Idealiskt bör dina RESTful API:er vara tillståndslösa, vilket innebär att servern inte bör lagra någon klientsessionsinformation. När en giltig begäran kommer in, bör servern bara svara med den begärda data. Det är här token kommer in i bilden. Så, vilken typ av token ska du använda i ett sådant fall?
I OAuth 2.0 och OIDC, behandlas varje skyddad API som en resurs. Åtkomsttoken är den token som klienten sänder till servern vid begäran av en API-resurs, vanligtvis via begäranshuvudet och i JWT format.
På serversidan, när en begäran kommer in, behöver servern bara validera om inkommande begäran bär en giltig åtkomsttoken. Valideringsprocessen inkluderar vanligtvis att avkoda JWT-token, verifiera signatur och utgångstid, samt omfattningskravet för att säkerställa att klienten har de nödvändiga tillstånden.
Men du kanske funderar: Om min klientapplikation kan ha en giltig åtkomsttoken efter en framgångsrik inloggning, och använda åtkomsttoken för att begära server-API:er, är inte det tillräckligt? Varför behöver jag de andra token?
Frågan är giltig, och låt oss förklara steg för steg.
Medan åtkomsttoken tekniskt sett uppfyller de minimikrav som krävs för att systemet ska fungera, så på grund av säkerhetsproblem är åtkomsttokennas giltighet vanligtvis mycket kort (vanligtvis en timme). Så föreställ dig om vi bara har åtkomsttoken, slutanvändarna skulle behöva autentisera om varje gång åtkomsttoken löper ut. För moderna enkel-sides web-applikationer (SPA) och särskilt mobilapplikationer är frekventa utloggningar en ganska smärtsam användarupplevelse, även om vi bara försöker skydda deras användarsäkerhet.
Därför behöver vi en balans mellan tokensäkerhet och användarbekvämlighet. Därför introduceras uppfräscha token.
Åtkomsttoken används för att få tillgång till API-resurser, så deras kortlivade natur hjälper till att minska risken för att de läcker eller utsätts för intrång. Å andra sidan, eftersom uppfräscha token bara används för att bytas mot nya åtkomsttoken, används de inte lika frekvent som åtkomsttoken och därmed minskar risken för exponering. Därför anses det acceptabelt att ha en längre giltighetstid för uppfräscha token.
Eftersom uppfräscha token också lagras på klientsidan, är det en utmaning att säkerställa att de inte utsätts för kompromettering, särskilt för öppna klienter såsom enkel-sides web-applikationer (SPA) och mobilappar.
I Logto har uppfräscha token en automatisk rotationsmekanism aktiverad som standard, vilket innebär att auktorisationsservern kommer att utfärda en ny uppfräscha token när den uppfyller kriterierna:
Även om du fortfarande har möjlighet att stänga av rotation av uppfräscha token på applikationsdetaljsidan i administrationskonsolen, rekommenderas det starkt att behålla denna skyddsåtgärd.
ID-token är en unik funktion i OIDC som ger identitetsinformation om den autentiserade användaren.
Medan åtkomsttoken används för att få tillgång till skyddade resurser och uppfräscha token används för att få nya åtkomsttoken, används ID-token vanligtvis för att cacha användarinformation på klientsidan, vilket minskar behovet av att göra ytterligare begäranden till auktorisationsservern för användardata. I de flesta fall är det till och med säkert att säga att ha ID-token är likvärdigt med att användaren är autentiserad.
Inom OIDC-protokollet samarbetar uppfräscha token, åtkomsttoken och ID-token för att tillhandahålla säker och sömlös användarautentisering.
Att förstå dessa tokens roller och betydelse är avgörande för utvecklare som implementerar OIDC-autentisering i sina applikationer.