## Introduktion [OpenID Connect Protocol](https://openid.net/specs/openid-connect-core-1_0.html), ä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 resurstillstånd, är OIDC protokollet som standardiserar och stärker klients autentisering, med hjälp av den nyintroducerade ID-token. Vänta... Du kanske har hört talas om refresh-token och access-token under OAuth-eran, och nu kommer ett nytt koncept i OIDC? Förstår du verkligen skillnaderna mellan dessa tokens? [Logto](https://logto.io/), vår omfattande Customer Identity and Access Management (CIAM) lösning, är byggd ovanpå OIDC-protokollet. I vår community är en av de mest frekventa frågorna från våra användare: > **Vilka är skillnaderna mellan en refresh-token, en access-token och en ID-token?** Så i detta inlägg kommer vi att fördjupa oss i de viktigaste aspekterna av OIDC-tokens, samtidigt som vi belyser hur Logto förbättrar den övergripande utvecklarupplevelsen. Prova Logto Cloud på 5 minuter ## Låt oss börja med ett praktiskt scenario Föreställ dig att du arbetar med en typisk klient-server-applikation, och de kommunicerar med varandra genom RESTful API:er. Du vill hålla de flesta av dina API:er privata, vilket endast tillåter auktoriserade klienter att få åtkomst. Då kan du komma upp med den första frågan: ### Vilken typ av token behöver jag för att skydda mitt API? Det snabba svaret är: Access-token. I OIDC behandlas varje skyddat API som en resurs. Access-token är de legitimationer som klienten sänder till servern när de begär en API-resurs, vanligtvis via förfrågningshuvudet. På servern, när en begäran kommer in, behöver servern bara verifiera om den inkommande begäran har en giltig access-token. En access-token är en kortlivad legitimation som ger tillstånd att få tillgång till skyddade resurser på uppdrag av en användare. När en användare framgångsrikt autentiserar sig med hjälp av OIDC, utfärdar auktoriseringsservern en access-token. Denna token innehåller information om användaren, deras behörigheter och giltighetsperioden. Token skickas sedan med varje efterföljande begäran till resursservern, vilket gör det möjligt för servern att verifiera användarens identitet och godkänna tillgången till de begärda resurserna. Du kanske funderar: Om min klientapplikation kan få en giltig access-token efter en framgångsrik inloggning, och använda access-token för att begära server-API:er, är det inte tillräckligt? Varför behöver jag refresh-tokens och ID-tokens? Indeed, en giltig fråga, och låt oss förklara det steg för steg. ### Varför behöver vi refresh-tokens? Även om access-tokens tekniskt sett uppfyller minimikraven för att få systemet att fungera, så är deras giltighetstid vanligtvis mycket kort (vanligtvis en timme) på grund av säkerhetsaspekter. Så föreställ dig om vi bara har access-tokens måste slutanvändarna autentisera sig igen varje gång access-token löper ut. För moderna enkel-sides webcapplikationer och framförallt mobilapplikationer är det att logga ut ofta 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 token-säkerhet och användarkomfort. Det är därför OIDC introducerar refresh-tokens. En refresh-token är en längre livslängd token som används för att erhålla nya access-tokens utan att användaren behöver autentisera sig igen. Det är som en nyckel för att få flera nycklar. Refresh-tokens används när acess-token löper ut eller behöver förnyas. De har en längre giltighetsperiod jämfört med access-tokens, ofta varar de i dagar, veckor eller till och med månader. ### Varför kan refresh-tokens ha längre livslängd? Access-tokens används för att få åtkomst till API-resurser, så deras kortlivade natur hjälper till att minska risken för att de läcker eller komprometteras. Å andra sidan, eftersom refresh-tokens enbart används för att byta till nya access-tokens, används de inte lika ofta som access-tokens och därför är risken för exponering minskad. Därför anses det vara acceptabelt att ha en längre giltighetsperiod för refresh-tokens. ### Säkerställa refresh-token säkerhet Eftersom refresh-token också lagras på klientsidan, är det en utmaning att säkerställa att de inte komprometteras, särskilt för offentliga klienter som single-page webcapplikationer (SPA). I Logto har refresh-tokens en automatisk [rotationsmekanism](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13#section-4.12) aktiverad som standard, vilket innebär att auktoriseringsservern kommer att utfärda en ny refresh-token när den uppfyller kriteriet: - Enkel-sidiga applikationer: Kända som klienter utan avsändarbegränsning, dessa appar kräver refresh-token-rotation. Refresh-tokenens livslängd (TTL) kan inte specificeras. - Native-appar och traditionella webbappar: Refresh-token-rotering är intrinsiskt aktiverad och förnyas automatiskt vid nå 70% av dess TTL. [Läs mer](https://docs.logto.io/docs/references/applications/#rotate-refresh-token) Även om du fortfarande har möjlighet att inaktivera refresh-token-rotering på applikationsdetalsidan i admin-konsolen, rekommenderas starkt att behålla denna skyddsmetod. ### Kärnan i en ID-token [ID-token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) möjliggör för klienten att erhålla grundläggande användarinformation utan att begära servern. ID-token är en ny typ av token introducerad av OIDC som håller cachad användarautentisering information, vilket förbättrar prestanda och slutanvändarupplevelsen. Till skillnad från access-tokens, avsedda att förstås enbart av resursservern, är ID-tokens användarvänliga för klienten. När klienten gör en OIDC-exchangeförfrågan kan den begära en ID-token tillsammans med en access-token. ID-token är en JSON Web Token (JWT) som innehåller användarclaims som användarnamn, e-post, avatarbild, etc. Den är signerad av auktoriseringsservern och kan verifieras och avkodas av klienten offline. Detta är särskilt användbart för moderna enkel-sides webcapplikationer och mobilappar där klienten kan cachelagra ID-token och använda den för att bestämma användarens autentiseringsstatus, vilket i hög grad hjälper till med den övergripande prestandan och användarupplevelsen. Det är också viktigt att notera att ID-tokens inte används för att godkänna åtkomst till skyddade resurser; access-tokens uppfyller den rollen. I Logto använder vi också ID-token i våra SDK:er för att bestämma autentiseringsstatusen på klientsidan. Till exempel kan du se i våra [JS SDK:er](https://docs.logto.io/docs/references/applications/#rotate-refresh-token): ```tsx const isAuthenticated = Boolean(await this.getIdToken()); ``` Men som nämnts ovan är klient-SDK:s `isAuthenticated`-flagga bara en klientcachead status. Den realtids autentiseringsstatusen måste fortfarande fastställas av servern genom att validera refresh- och access-tokens. Vi tillhandahåller också en `getUserClaims()`-funktion i våra SDK:er för att hjälpa dig avkoda ID-token och få användarclaims. Dock uppdateras inte den cachelagrade statusen förrän användaren loggar in igen. Om du vill hämta realtidsanvändarinformation från OIDC-servern, använd istället `fetchUserInfo()`. ## Logtos fördelar och funktioner Logto är byggd strikt enligt OIDC-protokollet och erbjuder samtidigt ytterligare funktioner och fördelar för utvecklare och företag: 1. Praktiska SDK:er: Logto SDK:er effektiviserar tokenhantering åt dig. Du behöver inte manuellt lagra din refresh-token och access-token själv. Ring bara `getAccessToken()` varje gång så kommer SDK alltid försöka återanvända den lagrade access-token eller automatiskt förnya den om den gått ut. 2. Refresh-token-rotation: Logto tvingar refresh-token-rotationsmekanism för att se till att din refresh-token alltid förnyas efter att den konsumerats, vilket minskar risken för att den läcker eller komprometteras. Även om du fortfarande kan inaktivera den i admin-konsolen, rekommenderas det starkt att ha den aktiverad. 3. Optimerad prestanda: Med hjälp av ID-tokens kan du alltid få grundläggande användarinformation utan att begära servern. Använd `isAuthenticated`-status och `getIdTokenClaims()`-funktionen som tillhandahålls av Logto SDK:er för att kontrollera användarens autentiseringsstatus och avkoda användarclaims på klientsidan. 4. Förbättrad säkerhet: Logto tvingar säkra anslutningar mellan klienten och auktoriseringsservern med hjälp av HTTPS och TLS. Detta skyddar dina tokens från potentiellt stöld av obehöriga tredje parter och garanterar säkerheten för ditt system. ## Slutsats I OIDC-protokollet arbetar Refresh Tokens, Access Tokens och ID Tokens tillsammans för att tillhandahålla säker och sömlös användarautentisering. - Refresh-tokens eliminerar användarens inblandning för nya access-tokens. - Access-tokens tillhandahåller tillstånd för att få åtkomst till skyddade resurser. - ID-tokens tillhandahåller cachad användarinformation på klienten, vilket förbättrar prestanda. Att förstå rollen och betydelsen av dessa tokens är avgörande för utvecklare som implementerar OIDC-autentisering i sina applikationer. Genom att välja Logto kan utvecklare och företag låsa upp den fulla potentialen hos sådana OIDC-funktioner, integrera robusta och säkra autentiseringssystem som skyddar användardata och ger en sömlös användarupplevelse. Prova Logto Idag