Spring Security 6 og JWT-autentisering · leksjon

Kortlivede JWT-tokens og refresh-syklus

Implementer et robust system med kortlivede access-tokens og refresh-tokens med lengre levetid for økt sikkerhet.

Leksjon 1 av 412 trinn

Kortlivede JWT-tokens og refresh-syklus er en gratis leksjon i Spring Security 6 og JWT-autentisering på CoddyKit. Dette er leksjon 1 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Spring Security 6 og JWT-autentisering, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Spring Security 6 og JWT-autentisering inneholder totalt 4 leksjoner.

Kortlivede tokens og fornyelse

Velkommen til et avansert tema innen JWT-sikkerhet! Vi skal utforske hvordan du kan gjøre autentiseringssystemet ditt mer robust ved hjelp av short-lived access tokens og refresh tokens.

Denne strategien forbedrer sikkerheten betydelig ved å begrense tidsrommet angripere kan utnytte kompromitterte tokens.

Hvorfor kortlivede access tokens?

Access tokens er som en nøkkel til applikasjonens ressurser. Hvis en angriper får tak i et access token med lang levetid, kan angriperen utgi seg for å være brukeren i lang tid.

  • Redusert risiko: Kortere levetid betyr mindre tid til å misbruke et kompromittert token.
  • Raskere tilbakekalling: Selv om et token blir kompromittert, er gyldighetsperioden svært kort.
  • Forbedret sikkerhet: Tvinger frem hyppig ny autentisering (via refresh tokens), slik at kompromitterte økter kan oppdages tidligere.

Introduksjon til refresh tokens

Siden access tokens har kort levetid, måtte brukerne stadig logge inn på nytt. Det er her refresh tokens kommer inn!

Et refresh token er en legitimasjon med lang levetid som brukes til å hente et nytt, kortlivet access token uten at brukeren må oppgi legitimasjonen sin på nytt. De fungerer som en langsiktig nøkkel for å utstede kortsiktige nøkler på nytt.

Refresh token-syklusen

Slik fungerer den typiske flyten:

  1. Brukeren logger inn med legitimasjon.
  2. Serveren autentiserer brukeren og utsteder både et kortlivet access token og et langlivet refresh token.
  3. Klienten bruker access tokenet til API-kall.
  4. Når access tokenet utløper, sender klienten refresh tokenet til et spesielt endepunkt.
  5. Serveren validerer refresh tokenet og utsteder et nytt access token (og ofte også et nytt refresh token ved rotering).

Simulere token-utløp

La oss se for oss et enkelt token med svært kort utløpstid. I en virkelig applikasjon håndterer Spring Security mye av dette, men det er viktig å forstå konseptet.

Dette Java-utdraget viser hvordan et tokens gyldighet kan kontrolleres opp mot et utløpstidspunkt.

import java.time.Instant;
import java.time.temporal.ChronoUnit;

public class TokenChecker {
  public static void main(String[] args) {
    // Simulate a token issued now, expiring in 5 seconds
    Instant issuedAt = Instant.now();
    Instant expiresAt = issuedAt.plus(5, ChronoUnit.SECONDS);

    System.out.println("Token issued: " + issuedAt);
    System.out.println("Token expires: " + expiresAt);

    // After some time, check if token is valid
    Instant currentTime = Instant.now().plus(7, ChronoUnit.SECONDS);
    if (currentTime.isAfter(expiresAt)) {
      System.out.println("Token is expired at: " + currentTime);
    } else {
      System.out.println("Token is still valid.");
    }
  }
}

Generering av refresh-tokens

I motsetning til access-tokens (som ofte er JWT-er) er refresh-tokens vanligvis ugjennomsiktige strenger. De inneholder ikke brukerinformasjon direkte.

Når et refresh-token genereres, gjør serveren følgende:

  • Oppretter en kryptografisk sterk, tilfeldig streng.
  • Knytter den til en bruker-ID og en utløpsdato i et sikkert datalager (for eksempel en database eller Redis).
  • Setter en langt lengre utløpstid (for eksempel dager, uker eller måneder).

Sikker lagring på serversiden

Refresh-tokens bør aldri selv være JWT-er (med mindre de er kryptert og håndteres nøye), og de bør alltid lagres sikkert på serversiden.

Dette gjør det enkelt å tilbakekalle dem og hindrer manipulering på klientsiden. Vanlige lagringsalternativer er:

  • Database: Lagre tokenet, bruker-ID-en, utløpstidspunktet og eventuelt andre metadata.
  • Redis: Et utmerket alternativ for lagring med høy ytelse og raske oppslag, særlig med støtte for utløpstid.

Håndtering på klientsiden

På klientsiden (for eksempel i en nettleser eller mobilapp) må begge tokenene lagres sikkert:

  • Access-token: Lagres i minnet eller i lokal lagring (med forsiktighet) og sendes med hver API-forespørsel.
  • Refresh-token: Lagres på et sikrere sted, for eksempel i en HttpOnly-informasjonskapsel (på nettet) eller i sikker lagring (i mobilapper).

Klientens oppgave er å oppdage at et access-token har utløpt og deretter starte fornyelsesflyten.

Endepunkt for refresh-token (konsept)

Spring Boot-applikasjonen vil eksponere et spesifikt endepunkt, vanligvis /api/auth/refresh, for å håndtere forespørsler om fornyelse.

Når en forespørsel med et gyldig refresh-token når dette endepunktet, gjør serveren følgende:

  1. Validerer refresh-tokenet (om det finnes, utløpstidspunktet og tilknytningen til brukeren).
  2. Hvis tokenet er gyldig, genererer den et nytt access-token (og eventuelt et nytt refresh-token).
  3. Returnerer de nye tokenene til klienten.

Fordeler og sikkerhet ved fornyelsesflyten

Implementering av en fornyelsesflyt gir betydelige sikkerhetsfordeler:

  • Bedre tilbakekalling: Du kan umiddelbart tilbakekalle et refresh-token fra serveren og dermed ugyldiggjøre alle fremtidige forespørsler om access-tokens.
  • Rotering av tokens: Å utstede et nytt refresh-token ved hver fornyelsesforespørsel (og ugyldiggjøre det gamle) gir et ekstra sikkerhetslag.
  • Mindre eksponering: Langtidslevende legitimasjon (refresh-tokens) brukes sjeldnere og vanligvis over sikrere kanaler.

Test forståelsen

Hvilke av følgende er viktige fordeler ved å bruke en syklus med et kortlivet access-token og et refresh-token?

Oppsummering: Kortlivede JWT-er og fornyelse

Godt jobbet! I denne leksjonen har vi utforsket det viktige konseptet med å bruke kortlivede access-tokens sammen med langlivede refresh-tokens for å bygge et sikrere autentiseringssystem.

  • Kortlivede access-tokens begrenser eksponeringen hvis legitimasjon blir kompromittert.
  • Refresh-tokens gjør det mulig for brukere å hente nye access-tokens uten å autentisere seg på nytt.
  • Denne syklusen forbedrer sikkerheten gjennom bedre muligheter for tilbakekalling og redusert risiko.

Det er viktig å beherske dette mønsteret for å kunne utvikle robuste applikasjoner som er klare for produksjon.

Gratis å komme i gang

Lær deg Java med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
12
Leksjoner
48

Ofte stilte spørsmål

Er leksjonen «Kortlivede JWT-tokens og refresh-syklus» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Spring Security 6 og JWT-autentisering, inkludert «Kortlivede JWT-tokens og refresh-syklus», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Spring Security 6 og JWT-autentisering inneholder totalt 4 leksjoner.

Hva lærer jeg i «Kortlivede JWT-tokens og refresh-syklus»?

Implementer et robust system med kortlivede access-tokens og refresh-tokens med lengre levetid for økt sikkerhet. Du øver på Spring Security 6 og JWT-autentisering med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Spring Security 6 og JWT-autentisering?

Ingen tidligere erfaring er nødvendig. Spring Security 6 og JWT-autentisering på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 1 av 4.

Hvor lang tid tar leksjonen «Kortlivede JWT-tokens og refresh-syklus»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Spring Security 6 og JWT-autentisering-leksjonen?

Ja. Alle Spring Security 6 og JWT-autentisering-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Kortlivede JWT-tokens og refresh-syklus
  2. Svartelisting og hvitelisting av JWT-tokens
  3. Ytelsesbetraktninger for JWT
  4. Bufring av tokenvalidering for skalering
← Tilbake til Spring Security 6 og JWT-autentisering