Spring Security 6 och JWT-autentisering · Lektion

Säker lagring av token

Förstå bästa praxis för lagring av JWT-token och refresh tokens på klientsidan för att förhindra vanliga attacker.

Lektion 3 av 411 steg

Säker lagring av token är en gratis lektion i Spring Security 6 och JWT-autentisering på CoddyKit. Detta är lektion 3 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Spring Security 6 och JWT-autentisering, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Spring Security 6 och JWT-autentisering innehåller totalt 4 lektioner.

Varför säker lagring av tokens är viktig

När du bygger säkra applikationer med JWT:er är det avgörande var du lagrar dessa tokens på klientsidan. Felaktig lagring kan utsätta dina användare för olika säkerhetsrisker.

Den här lektionen går igenom bästa praxis för hantering av JWT:er och refresh tokens i klientmiljöer som webbläsare, så att applikationen förblir motståndskraftig mot vanliga attacker.

Alternativ för lagring på klientsidan

Webbläsare erbjuder flera sätt att lagra data, och varje sätt har olika säkerhetskonsekvenser för känsliga tokens:

  • LocalStorage: Lagrar data beständigt mellan webbläsarsessioner.
  • SessionStorage: Lagrar data endast så länge webbläsarsessionen pågår.
  • Cookies: Små mängder data som skickas av servern och lagras av webbläsaren, och som skickas tillbaka med efterföljande förfrågningar.

Att välja rätt alternativ är avgörande för tokensäkerheten.

Risker med LocalStorage och SessionStorage

Även om LocalStorage och SessionStorage är praktiska rekommenderas de vanligtvis inte för lagring av känsliga JWT:er eller refresh tokens.

De är sårbara för Cross-Site Scripting-attacker (XSS). Om ett skadligt skript injiceras på sidan kan det enkelt komma åt och stjäla tokens som lagras där.

XSS: Tokenstjuven

Cross-Site Scripting (XSS) är en vanlig sårbarhet i webbsäkerhet. Den gör det möjligt för angripare att injicera skadliga skript på webbsidor som visas för andra användare.

Dessa skript kan sedan:

  • Komma åt och stjäla data från LocalStorage eller SessionStorage.
  • Utföra åtgärder i användarens namn.
  • Till och med kapa användarsessioner.

Därför är tokens i dessa lagringsutrymmen mycket utsatta.

Introduktion till HTTP-Only-cookies

För bättre skydd mot XSS är HTTP-Only-cookies ett bra val, särskilt för refresh tokens. En HTTP-Only-cookie kan inte nås av JavaScript på klientsidan.

Det innebär att det skadliga skriptet inte kan läsa eller stjäla innehållet i cookien även om en XSS-attack inträffar, vilket minskar risken för att token komprometteras avsevärt.

Viktiga säkerhetsflaggor för cookies

Utöver HTTP-Only är två andra flaggor avgörande för cookiesäkerheten:

  • Secure: Säkerställer att cookien endast skickas över HTTPS-anslutningar. Använd aldrig känsliga cookies utan denna flagga i produktion.
  • SameSite: Förhindrar att webbläsaren skickar cookien med förfrågningar mellan olika webbplatser och ger ett robust skydd mot Cross-Site Request Forgery-attacker (CSRF).

Använd alltid Secure och en lämplig SameSite-policy (till exempel Lax eller Strict).

Ställa in en säker cookie i Spring

Så här kan en Spring Boot-backend ange en HTTP-Only-, Secure- och SameSite-cookie. Denna cookie innehåller vanligtvis en refresh token.

Webbläsaren hanterar automatiskt att skicka denna cookie med efterföljande förfrågningar till din domän, medan JavaScript inte kan komma åt den.

import jakarta.servlet.http.Cookie;
import jakarta.servlet.http.HttpServletResponse;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class CookieController {

    @GetMapping("/set-secure-cookie")
    public String setSecureCookie(HttpServletResponse response) {
        Cookie refreshTokenCookie = new Cookie("refreshToken", "your_long_refresh_token");
        refreshTokenCookie.setHttpOnly(true); // JS cannot access
        refreshTokenCookie.setSecure(true);   // Only over HTTPS
        refreshTokenCookie.setMaxAge(7 * 24 * 60 * 60); // 7 days
        refreshTokenCookie.setPath("/");
        // Set SameSite to Lax or Strict for CSRF protection
        // Note: For Spring, SameSite often set via application properties
        // or a custom filter for older Servlet versions.
        // With modern Servlet API (e.g., Servlet 4+), can be set directly:
        // refreshTokenCookie.setAttribute("SameSite", "Lax");

        response.addCookie(refreshTokenCookie);
        return "Secure cookie set!";
    }

    public static void main(String[] args) {
        // This is a conceptual example for a Spring Controller.
        // A full Spring Boot app would run this via SpringApplication.run().
        // The main method here is just for completeness as per guidelines,
        // but this code needs a Spring context to fully execute.
        System.out.println("To run, integrate into a Spring Boot application.");
    }
}

Lagring av access tokens: i minnet

Access tokens har vanligtvis kort livslängd. Den säkraste platsen för en access token på klientsidan är ofta i minnet (till exempel i en JavaScript-variabel).

Det innebär att token inte skrivs till beständig lagring och går förlorad när webbläsarfliken stängs eller sidan uppdateras. Det minimerar exponeringen, eftersom en XSS-attack bara skulle kunna stjäla token medan användaren aktivt befinner sig på den komprometterade sidan.

Den kombinerade säkra strategin

En robust strategi kombinerar det bästa av två världar:

  • Access Token: Lagra den i en JavaScript-variabel (i minnet). Skicka den i Authorization-huvudet vid API-förfrågningar. Den har kort livslängd.
  • Refresh Token: Lagra den i en HTTP-Only-, Secure-, SameSite-cookie. Denna token används för att hämta nya access tokens när den aktuella löper ut. Den har längre livslängd och är väl skyddad.

Detta tillvägagångssätt balanserar användbarhet med starkt skydd mot XSS och CSRF.

Testa dina kunskaper

Vilka av följande anses vara bästa praxis för säker lagring av JWT:er och refresh tokens på klientsidan?

Sammanfattning: principer för säker lagring

Du har lärt dig viktiga strategier för säker lagring av tokens på klientsidan:

  • Undvik LocalStorage/SessionStorage för känsliga tokens på grund av XSS-risker.
  • Använd HTTP-Only-, Secure- och SameSite-cookies för refresh tokens för att skydda mot XSS och CSRF.
  • Förvara access tokens i minnet (i JavaScript-variabler), eftersom de har kort livslängd.

Genom att följa dessa metoder förbättrar du säkerheten i ditt JWT-baserade autentiseringssystem avsevärt.

Gratis att börja

Lär dig Java med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
12
Lektioner
48

Vanliga frågor

Är lektionen ”Säker lagring av token” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Spring Security 6 och JWT-autentisering, inklusive ”Säker lagring av token”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Spring Security 6 och JWT-autentisering innehåller totalt 4 lektioner.

Vad lär jag mig i ”Säker lagring av token”?

Förstå bästa praxis för lagring av JWT-token och refresh tokens på klientsidan för att förhindra vanliga attacker. Ni övar på Spring Security 6 och JWT-autentisering med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Spring Security 6 och JWT-autentisering?

Du behöver inga förkunskaper. Utbildningen i Spring Security 6 och JWT-autentisering på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.

Hur lång tid tar lektionen ”Säker lagring av token”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Spring Security 6 och JWT-autentisering-lektionen?

Ja. Varje Spring Security 6 och JWT-autentisering-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Implementering av refresh tokens
  2. Strategier för återkallning av JWT-token
  3. Säker lagring av token
  4. Rotera signeringsnycklar och hantera nycklar
← Tillbaka till Spring Security 6 och JWT-autentisering