Apparaatgebonden sessiereferenties (DBSC)

Stay organized with collections Save and categorize content based on your preferences.

Device Bound Session Credentials (DBSC) versterken de authenticatie door hardware-ondersteunde sessiebeveiliging toe te voegen.

Daniel Rubery

José Luis Zapata

Invoering

Veel websites vertrouwen op cookies met een lange levensduur voor gebruikersauthenticatie, maar deze zijn gevoelig voor sessiekaping. Device Bound Session Credentials (DBSC) voegt een laag hardware-ondersteunde beveiliging toe om dit risico te beperken en ervoor te zorgen dat sessies aan specifieke apparaten zijn gebonden.

Deze handleiding is bedoeld voor ontwikkelaars die authenticatiestromen in webapplicaties onderhouden. Er wordt uitgelegd hoe DBSC werkt en hoe u het in uw site kunt integreren.

Hoe DBSC werkt

Op een hoog niveau introduceert DBSC een cryptografisch sleutelpaar dat is gekoppeld aan het apparaat van de gebruiker. Chrome genereert dit sleutelpaar tijdens het inloggen en slaat de privésleutel op in beveiligde hardware, zoals een Trusted Platform Module (TPM) , indien beschikbaar. Sessies maken gebruik van kortstondige cookies. Wanneer een van deze cookies verloopt, bewijst Chrome het bezit van de privésleutel voordat deze wordt vernieuwd. Dit proces koppelt de sessiecontinuïteit aan het originele apparaat.

Als het apparaat van een gebruiker geen veilige sleutelopslag ondersteunt, valt DBSC netjes terug naar het standaardgedrag zonder de authenticatiestroom te onderbreken.

Implementatie overzicht

Om DBSC in uw applicatie te integreren, moet u de volgende wijzigingen aanbrengen:

• Wijzig uw aanmeldingsstroom zodat deze een Sec-Session-Registration header bevat.
• Voeg een sessieregistratie-eindpunt toe dat:
  • Koppelt een openbare sleutel aan de sessie van de gebruiker.
  • Serveert sessieconfiguratie.
  • Overgangen naar kortstondige cookies.
• Voeg een vernieuwingseindpunt toe om de cookievernieuwing en de validatie van het sleutelbezit af te handelen.

Voor de meeste van uw bestaande eindpunten zijn geen wijzigingen vereist. DBSC is ontworpen om additief en niet-verstorend te zijn.

Wanneer een vereiste kortstondige cookie ontbreekt of is verlopen, pauzeert Chrome het verzoek en probeert de cookie te vernieuwen. Hierdoor kan uw app de gebruikelijke sessiecookiecontroles blijven gebruiken om te bevestigen dat de gebruiker is aangemeld. Omdat dit overeenkomt met typische authenticatiestromen, werkt DBSC met minimale wijzigingen in uw aanmeldingslogica.

Implementatiestappen

In dit gedeelte worden de noodzakelijke wijzigingen aan uw authenticatiesysteem besproken, inclusief hoe u uw inlogproces kunt wijzigen, sessieregistratie kunt afhandelen en kortstondige cookievernieuwingen kunt beheren. Elke stap is ontworpen om soepel te integreren met uw bestaande infrastructuur.

De implementatiestappen volgen de algemene stroom die een aangemelde gebruiker zou ervaren wanneer DBSC actief is: registratie bij het inloggen, gevolgd door regelmatige, kortstondige cookievernieuwingen. U kunt elke stap afzonderlijk testen en implementeren, afhankelijk van het sessiegevoeligheidsniveau van uw app.

1. Wijzig de inlogstroom

Nadat de gebruiker zich heeft aangemeld, reageert u met een cookie met een lange levensduur en een Sec-Session-Registration header. Bijvoorbeeld:

De volgende HTTP-antwoordheader wordt geretourneerd na succesvolle sessieregistratie:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Als het apparaat beveiligde sleutelopslag ondersteunt, maakt Chrome contact met het /StartSession -eindpunt met een openbare sleutel in een JSON Web Token (JWT).

De auth_cookie in dit voorbeeld vertegenwoordigt uw sessietoken. U kunt deze cookie een naam geven die u maar wilt, zolang deze maar overeenkomt met het name in uw sessieconfiguratie en consistent wordt gebruikt in uw hele toepassing.

2. Implementeer het sessieregistratie-eindpunt

Bij /StartSession moet uw server:

• Koppel de ontvangen publieke sleutel aan de sessie van de gebruiker.
• Reageer met een sessieconfiguratie.
• Vervang het langlevende koekje door een kortlevend koekje.

In het volgende voorbeeld is de kortstondige cookie geconfigureerd om na 10 minuten te verlopen:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Implementeer het vernieuwingseindpunt

Wanneer de kortstondige cookie verloopt, initieert Chrome een vernieuwingsstroom om het bezit van de privésleutel te bewijzen. Dit proces omvat gecoördineerde acties van zowel Chrome als uw server:

1. Chrome stelt het verzoek van de gebruiker aan uw applicatie uit en stuurt een vernieuwingsverzoek naar /RefreshEndpoint :

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   

2. Uw server reageert met een uitdaging:

   HTTP/1.1 401 Unauthorized
   Sec-Session-Challenge: "challenge_value"
   

3. Chrome ondertekent de uitdaging met de opgeslagen privésleutel en voert het verzoek opnieuw uit:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   Sec-Session-Response: <JWT proof>
   

4. Uw server valideert het ondertekende bewijs en geeft een vernieuwd kortstondig cookie uit:

   HTTP/1.1 200 OK
   
   Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
   

5. Chrome ontvangt de vernieuwde cookie en hervat het oorspronkelijke uitgestelde verzoek.

Alternatief integratiepatroon

Om de veerkracht te verbeteren, kunnen sites naast de kortstondige cookie een tweede, niet-DBSC-cookie toevoegen. Deze cookie met lange levensduur wordt alleen gebruikt om nieuwe tokens met een korte levensduur uit te geven en helpt onderscheid te maken tussen werkelijk niet-geverifieerde verzoeken en tijdelijke DBSC-fouten.

• De cookie met lange levensduur blijft bestaan, zelfs als DBSC mislukt.
• De kortstondige cookie wordt vernieuwd met behulp van DBSC en is vereist voor gevoelige bewerkingen.

Dit patroon geeft sites meer controle over hoe om te gaan met randgevallen.

Voorbehoud en terugvalgedrag

Chrome kan DBSC-bewerkingen overslaan en verzoeken verzenden zonder de door DBSC beheerde kortstondige cookie in de volgende scenario's:

• Het vernieuwingseindpunt is onbereikbaar vanwege netwerkfouten of serverproblemen.
• De TPM is bezet of ondervindt ondertekeningsfouten. Omdat de TPM wordt gedeeld door systeemprocessen, kunnen excessieve vernieuwingen de snelheidslimieten overschrijden.
• De door de DBSC beheerde kortstondige cookie is een cookie van derden en de gebruiker heeft cookies van derden geblokkeerd in zijn browserinstellingen.

In deze situaties valt Chrome terug op het gebruik van de langlevende cookie als deze nog aanwezig is. Deze fallback werkt alleen als uw implementatie zowel een cookie met een lange levensduur als een cookie met een korte levensduur bevat. Als dit niet het geval is, verzendt Chrome het verzoek zonder cookie.

Samenvatting

Apparaatgebonden sessiereferenties verbeteren de sessiebeveiliging met minimale wijzigingen aan uw applicatie. Ze bieden sterkere bescherming tegen het kapen van sessies door sessies aan specifieke apparaten te koppelen. De meeste gebruikers profiteren hiervan zonder enige verstoring te ervaren, en DBSC valt gracieus terug op niet-ondersteunde hardware.

Raadpleeg de DBSC-specificatie voor meer informatie.

Device Bound Session Credentials (DBSC) versterken de authenticatie door hardware-ondersteunde sessiebeveiliging toe te voegen.

Daniel Rubery

José Luis Zapata

Invoering

Veel websites vertrouwen op cookies met een lange levensduur voor gebruikersauthenticatie, maar deze zijn gevoelig voor sessiekaping. Device Bound Session Credentials (DBSC) voegt een laag hardware-ondersteunde beveiliging toe om dit risico te beperken en ervoor te zorgen dat sessies aan specifieke apparaten zijn gebonden.

Deze handleiding is bedoeld voor ontwikkelaars die authenticatiestromen in webapplicaties onderhouden. Er wordt uitgelegd hoe DBSC werkt en hoe u het in uw site kunt integreren.

Hoe DBSC werkt

Op een hoog niveau introduceert DBSC een cryptografisch sleutelpaar dat is gekoppeld aan het apparaat van de gebruiker. Chrome genereert dit sleutelpaar tijdens het inloggen en slaat de privésleutel op in beveiligde hardware, zoals een Trusted Platform Module (TPM) , indien beschikbaar. Sessies maken gebruik van kortstondige cookies. Wanneer een van deze cookies verloopt, bewijst Chrome het bezit van de privésleutel voordat deze wordt vernieuwd. Dit proces koppelt de sessiecontinuïteit aan het originele apparaat.

Als het apparaat van een gebruiker geen veilige sleutelopslag ondersteunt, valt DBSC netjes terug naar het standaardgedrag zonder de authenticatiestroom te onderbreken.

Implementatie overzicht

Om DBSC in uw applicatie te integreren, moet u de volgende wijzigingen aanbrengen:

• Wijzig uw aanmeldingsstroom zodat deze een Sec-Session-Registration header bevat.
• Voeg een sessieregistratie-eindpunt toe dat:
  • Koppelt een openbare sleutel aan de sessie van de gebruiker.
  • Serveert sessieconfiguratie.
  • Overgangen naar kortstondige cookies.
• Voeg een vernieuwingseindpunt toe om de cookievernieuwing en de validatie van het sleutelbezit af te handelen.

Voor de meeste van uw bestaande eindpunten zijn geen wijzigingen vereist. DBSC is ontworpen om additief en niet-verstorend te zijn.

Wanneer een vereiste kortstondige cookie ontbreekt of is verlopen, pauzeert Chrome het verzoek en probeert de cookie te vernieuwen. Hierdoor kan uw app de gebruikelijke sessiecookiecontroles blijven gebruiken om te bevestigen dat de gebruiker is aangemeld. Omdat dit overeenkomt met de typische authenticatiestromen, werkt DBSC met minimale wijzigingen in uw aanmeldingslogica.

Implementatiestappen

In dit gedeelte worden de noodzakelijke wijzigingen aan uw authenticatiesysteem besproken, inclusief hoe u uw inlogproces kunt wijzigen, sessieregistratie kunt afhandelen en kortstondige cookievernieuwingen kunt beheren. Elke stap is ontworpen om soepel te integreren met uw bestaande infrastructuur.

De implementatiestappen volgen de algemene stroom die een aangemelde gebruiker zou ervaren wanneer DBSC actief is: registratie bij het inloggen, gevolgd door regelmatige, kortstondige cookievernieuwingen. U kunt elke stap afzonderlijk testen en implementeren, afhankelijk van het sessiegevoeligheidsniveau van uw app.

1. Wijzig de inlogstroom

Nadat de gebruiker zich heeft aangemeld, reageert u met een cookie met een lange levensduur en een Sec-Session-Registration header. Bijvoorbeeld:

De volgende HTTP-antwoordheader wordt geretourneerd na succesvolle sessieregistratie:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Als het apparaat beveiligde sleutelopslag ondersteunt, maakt Chrome contact met het /StartSession -eindpunt met een openbare sleutel in een JSON Web Token (JWT).

De auth_cookie in dit voorbeeld vertegenwoordigt uw sessietoken. U kunt deze cookie een naam geven die u maar wilt, zolang deze maar overeenkomt met het name in uw sessieconfiguratie en consistent wordt gebruikt in uw hele applicatie.

2. Implementeer het sessieregistratie-eindpunt

Bij /StartSession moet uw server:

• Koppel de ontvangen publieke sleutel aan de sessie van de gebruiker.
• Reageer met een sessieconfiguratie.
• Vervang het langlevende koekje door een kortlevend koekje.

In het volgende voorbeeld is de kortstondige cookie geconfigureerd om na 10 minuten te verlopen:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Implementeer het vernieuwingseindpunt

Wanneer de kortstondige cookie verloopt, initieert Chrome een vernieuwingsstroom om het bezit van de privésleutel te bewijzen. Dit proces omvat gecoördineerde acties van zowel Chrome als uw server:

1. Chrome stelt het verzoek van de gebruiker aan uw applicatie uit en stuurt een vernieuwingsverzoek naar /RefreshEndpoint :

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   

2. Uw server reageert met een uitdaging:

   HTTP/1.1 401 Unauthorized
   Sec-Session-Challenge: "challenge_value"
   

3. Chrome ondertekent de uitdaging met de opgeslagen privésleutel en voert het verzoek opnieuw uit:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   Sec-Session-Response: <JWT proof>
   

4. Uw server valideert het ondertekende bewijs en geeft een vernieuwd kortstondig cookie uit:

   HTTP/1.1 200 OK
   
   Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
   

5. Chrome ontvangt de vernieuwde cookie en hervat het oorspronkelijke uitgestelde verzoek.

Alternatief integratiepatroon

Om de veerkracht te verbeteren, kunnen sites naast de kortstondige cookie een tweede, niet-DBSC-cookie toevoegen. Deze cookie met een lange levensduur wordt alleen gebruikt om nieuwe tokens met een korte levensduur uit te geven en helpt onderscheid te maken tussen werkelijk niet-geverifieerde verzoeken en tijdelijke DBSC-fouten.

• De cookie met lange levensduur blijft bestaan, zelfs als DBSC mislukt.
• De kortstondige cookie wordt vernieuwd met behulp van DBSC en is vereist voor gevoelige bewerkingen.

Dit patroon geeft sites meer controle over hoe om te gaan met randgevallen.

Voorbehoud en terugvalgedrag

Chrome kan DBSC-bewerkingen overslaan en verzoeken verzenden zonder de door DBSC beheerde kortstondige cookie in de volgende scenario's:

• Het vernieuwingseindpunt is onbereikbaar vanwege netwerkfouten of serverproblemen.
• De TPM is bezet of ondervindt ondertekeningsfouten. Omdat de TPM wordt gedeeld door systeemprocessen, kunnen excessieve vernieuwingen de snelheidslimieten overschrijden.
• De door de DBSC beheerde kortstondige cookie is een cookie van derden en de gebruiker heeft cookies van derden geblokkeerd in zijn browserinstellingen.

In deze situaties valt Chrome terug op het gebruik van de langlevende cookie als deze nog aanwezig is. Deze fallback werkt alleen als uw implementatie zowel een cookie met een lange levensduur als een cookie met een korte levensduur bevat. Als dit niet het geval is, verzendt Chrome het verzoek zonder cookie.

Samenvatting

Apparaatgebonden sessiereferenties verbeteren de sessiebeveiliging met minimale wijzigingen aan uw applicatie. Ze bieden sterkere bescherming tegen het kapen van sessies door sessies aan specifieke apparaten te koppelen. De meeste gebruikers profiteren hiervan zonder enige verstoring te ervaren, en DBSC valt gracieus terug op niet-ondersteunde hardware.

Raadpleeg de DBSC-specificatie voor meer informatie.

Device Bound Session Credentials (DBSC) versterken de authenticatie door hardware-ondersteunde sessiebeveiliging toe te voegen.

Daniel Rubery

José Luis Zapata

Invoering

Veel websites vertrouwen op cookies met een lange levensduur voor gebruikersauthenticatie, maar deze zijn gevoelig voor sessiekaping. Device Bound Session Credentials (DBSC) voegt een laag hardware-ondersteunde beveiliging toe om dit risico te beperken en ervoor te zorgen dat sessies aan specifieke apparaten zijn gebonden.

Deze handleiding is bedoeld voor ontwikkelaars die authenticatiestromen in webapplicaties onderhouden. Er wordt uitgelegd hoe DBSC werkt en hoe u het in uw site kunt integreren.

Hoe DBSC werkt

Op een hoog niveau introduceert DBSC een cryptografisch sleutelpaar dat is gekoppeld aan het apparaat van de gebruiker. Chrome genereert dit sleutelpaar tijdens het inloggen en slaat de privésleutel op in beveiligde hardware, zoals een Trusted Platform Module (TPM) , indien beschikbaar. Sessies maken gebruik van kortstondige cookies. Wanneer een van deze cookies verloopt, bewijst Chrome het bezit van de privésleutel voordat deze wordt vernieuwd. Dit proces koppelt de sessiecontinuïteit aan het originele apparaat.

Als het apparaat van een gebruiker geen veilige sleutelopslag ondersteunt, valt DBSC netjes terug naar het standaardgedrag zonder de authenticatiestroom te onderbreken.

Implementatie overzicht

Om DBSC in uw applicatie te integreren, moet u de volgende wijzigingen aanbrengen:

• Wijzig uw aanmeldingsstroom zodat deze een Sec-Session-Registration header bevat.
• Voeg een sessieregistratie-eindpunt toe dat:
  • Koppelt een openbare sleutel aan de sessie van de gebruiker.
  • Serveert sessieconfiguratie.
  • Overgangen naar kortstondige cookies.
• Voeg een vernieuwingseindpunt toe om de cookievernieuwing en de validatie van het sleutelbezit af te handelen.

Voor de meeste van uw bestaande eindpunten zijn geen wijzigingen vereist. DBSC is ontworpen om additief en niet-verstorend te zijn.

Wanneer een vereiste kortstondige cookie ontbreekt of is verlopen, pauzeert Chrome het verzoek en probeert de cookie te vernieuwen. Hierdoor kan uw app de gebruikelijke sessiecookiecontroles blijven gebruiken om te bevestigen dat de gebruiker is aangemeld. Omdat dit overeenkomt met de typische authenticatiestromen, werkt DBSC met minimale wijzigingen in uw aanmeldingslogica.

Implementatiestappen

In dit gedeelte worden de noodzakelijke wijzigingen aan uw authenticatiesysteem besproken, inclusief hoe u uw inlogproces kunt wijzigen, sessieregistratie kunt afhandelen en kortstondige cookievernieuwingen kunt beheren. Elke stap is ontworpen om soepel te integreren met uw bestaande infrastructuur.

De implementatiestappen volgen de algemene stroom die een aangemelde gebruiker zou ervaren wanneer DBSC actief is: registratie bij het inloggen, gevolgd door regelmatige, kortstondige cookievernieuwingen. U kunt elke stap afzonderlijk testen en implementeren, afhankelijk van het sessiegevoeligheidsniveau van uw app.

1. Wijzig de inlogstroom

Nadat de gebruiker zich heeft aangemeld, reageert u met een cookie met een lange levensduur en een Sec-Session-Registration header. Bijvoorbeeld:

De volgende HTTP-antwoordheader wordt geretourneerd na succesvolle sessieregistratie:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Als het apparaat beveiligde sleutelopslag ondersteunt, maakt Chrome contact met het /StartSession -eindpunt met een openbare sleutel in een JSON Web Token (JWT).

De auth_cookie in dit voorbeeld vertegenwoordigt uw sessietoken. U kunt deze cookie een naam geven die u maar wilt, zolang deze maar overeenkomt met het name in uw sessieconfiguratie en consistent wordt gebruikt in uw hele toepassing.

2. Implementeer het sessieregistratie-eindpunt

Bij /StartSession moet uw server:

• Koppel de ontvangen publieke sleutel aan de sessie van de gebruiker.
• Reageer met een sessieconfiguratie.
• Vervang het langlevende koekje door een kortlevend koekje.

In het volgende voorbeeld is de kortstondige cookie geconfigureerd om na 10 minuten te verlopen:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Implementeer het vernieuwingseindpunt

Wanneer de kortstondige cookie verloopt, initieert Chrome een vernieuwingsstroom om het bezit van de privésleutel te bewijzen. Dit proces omvat gecoördineerde acties van zowel Chrome als uw server:

1. Chrome stelt het verzoek van de gebruiker aan uw applicatie uit en stuurt een vernieuwingsverzoek naar /RefreshEndpoint :

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   

2. Uw server reageert met een uitdaging:

   HTTP/1.1 401 Unauthorized
   Sec-Session-Challenge: "challenge_value"
   

3. Chrome ondertekent de uitdaging met de opgeslagen privésleutel en voert het verzoek opnieuw uit:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   Sec-Session-Response: <JWT proof>
   

4. Uw server valideert het ondertekende bewijs en geeft een vernieuwd kortstondig cookie uit:

   HTTP/1.1 200 OK
   
   Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
   

5. Chrome ontvangt de vernieuwde cookie en hervat het oorspronkelijke uitgestelde verzoek.

Alternatief integratiepatroon

Om de veerkracht te verbeteren, kunnen sites naast de kortstondige cookie een tweede, niet-DBSC-cookie toevoegen. Deze cookie met een lange levensduur wordt alleen gebruikt om nieuwe tokens met een korte levensduur uit te geven en helpt onderscheid te maken tussen werkelijk niet-geverifieerde verzoeken en tijdelijke DBSC-fouten.

• De cookie met lange levensduur blijft bestaan, zelfs als DBSC mislukt.
• De kortstondige cookie wordt vernieuwd met behulp van DBSC en is vereist voor gevoelige bewerkingen.

Dit patroon geeft sites meer controle over hoe om te gaan met randgevallen.

Voorbehoud en terugvalgedrag

Chrome kan DBSC-bewerkingen overslaan en verzoeken verzenden zonder de door DBSC beheerde kortstondige cookie in de volgende scenario's:

• Het vernieuwingseindpunt is onbereikbaar vanwege netwerkfouten of serverproblemen.
• De TPM is bezet of ondervindt ondertekeningsfouten. Omdat de TPM wordt gedeeld door systeemprocessen, kunnen excessieve vernieuwingen de snelheidslimieten overschrijden.
• De door de DBSC beheerde kortstondige cookie is een cookie van derden en de gebruiker heeft cookies van derden geblokkeerd in zijn browserinstellingen.

In deze situaties valt Chrome terug op het gebruik van de langlevende cookie als deze nog aanwezig is. Deze fallback werkt alleen als uw implementatie zowel een cookie met een lange levensduur als een cookie met een korte levensduur bevat. Als dit niet het geval is, verzendt Chrome het verzoek zonder cookie.

Samenvatting

Apparaatgebonden sessiereferenties verbeteren de sessiebeveiliging met minimale wijzigingen aan uw applicatie. Ze bieden sterkere bescherming tegen het kapen van sessies door sessies aan specifieke apparaten te koppelen. De meeste gebruikers profiteren hiervan zonder enige verstoring te ervaren, en DBSC valt gracieus terug op niet-ondersteunde hardware.

Raadpleeg de DBSC-specificatie voor meer informatie.

Device Bound Session Credentials (DBSC) versterken de authenticatie door hardware-ondersteunde sessiebeveiliging toe te voegen.

Daniel Rubery

José Luis Zapata

Invoering

Veel websites vertrouwen op cookies met een lange levensduur voor gebruikersauthenticatie, maar deze zijn gevoelig voor sessiekaping. Device Bound Session Credentials (DBSC) voegt een laag hardware-ondersteunde beveiliging toe om dit risico te beperken en ervoor te zorgen dat sessies aan specifieke apparaten zijn gebonden.

Deze handleiding is bedoeld voor ontwikkelaars die authenticatiestromen in webapplicaties onderhouden. Er wordt uitgelegd hoe DBSC werkt en hoe u het in uw site kunt integreren.

Hoe DBSC werkt

Op een hoog niveau introduceert DBSC een cryptografisch sleutelpaar dat is gekoppeld aan het apparaat van de gebruiker. Chrome genereert dit sleutelpaar tijdens het inloggen en slaat de privésleutel op in beveiligde hardware, zoals een Trusted Platform Module (TPM) , indien beschikbaar. Sessies maken gebruik van kortstondige cookies. Wanneer een van deze cookies verloopt, bewijst Chrome het bezit van de privésleutel voordat deze wordt vernieuwd. Dit proces koppelt de sessiecontinuïteit aan het originele apparaat.

Als het apparaat van een gebruiker geen veilige sleutelopslag ondersteunt, valt DBSC netjes terug naar het standaardgedrag zonder de authenticatiestroom te onderbreken.

Implementatie overzicht

Om DBSC in uw applicatie te integreren, moet u de volgende wijzigingen aanbrengen:

• Wijzig uw aanmeldingsstroom zodat deze een Sec-Session-Registration header bevat.
• Voeg een sessieregistratie-eindpunt toe dat:
  • Koppelt een openbare sleutel aan de sessie van de gebruiker.
  • Serveert sessieconfiguratie.
  • Overgangen naar kortstondige cookies.
• Voeg een vernieuwingseindpunt toe om de cookievernieuwing en de validatie van het sleutelbezit af te handelen.

Voor de meeste van uw bestaande eindpunten zijn geen wijzigingen vereist. DBSC is ontworpen om additief en niet-verstorend te zijn.

Wanneer een vereiste kortstondige cookie ontbreekt of is verlopen, pauzeert Chrome het verzoek en probeert de cookie te vernieuwen. Hierdoor kan uw app de gebruikelijke sessiecookiecontroles blijven gebruiken om te bevestigen dat de gebruiker is aangemeld. Omdat dit overeenkomt met de typische authenticatiestromen, werkt DBSC met minimale wijzigingen in uw aanmeldingslogica.

Implementatiestappen

In dit gedeelte worden de noodzakelijke wijzigingen aan uw authenticatiesysteem besproken, inclusief hoe u uw inlogproces kunt wijzigen, sessieregistratie kunt afhandelen en kortstondige cookievernieuwingen kunt beheren. Elke stap is ontworpen om soepel te integreren met uw bestaande infrastructuur.

De implementatiestappen volgen de algemene stroom die een aangemelde gebruiker zou ervaren wanneer DBSC actief is: registratie bij het inloggen, gevolgd door regelmatige, kortstondige cookievernieuwingen. U kunt elke stap afzonderlijk testen en implementeren, afhankelijk van het sessiegevoeligheidsniveau van uw app.

1. Wijzig de inlogstroom

Nadat de gebruiker zich heeft aangemeld, reageert u met een cookie met een lange levensduur en een Sec-Session-Registration header. Bijvoorbeeld:

De volgende HTTP-antwoordheader wordt geretourneerd na succesvolle sessieregistratie:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Als het apparaat beveiligde sleutelopslag ondersteunt, maakt Chrome contact met het /StartSession -eindpunt met een openbare sleutel in een JSON Web Token (JWT).

De auth_cookie in dit voorbeeld vertegenwoordigt uw sessietoken. U kunt deze cookie een naam geven die u maar wilt, zolang deze maar overeenkomt met het name in uw sessieconfiguratie en consistent wordt gebruikt in uw hele toepassing.

2. Implementeer het sessieregistratie-eindpunt

Bij /StartSession moet uw server:

• Koppel de ontvangen publieke sleutel aan de sessie van de gebruiker.
• Reageer met een sessieconfiguratie.
• Vervang het langlevende koekje door een kortlevend koekje.

In het volgende voorbeeld is de kortstondige cookie geconfigureerd om na 10 minuten te verlopen:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Implementeer het vernieuwingseindpunt

Wanneer de kortstondige cookie verloopt, initieert Chrome een vernieuwingsstroom om het bezit van de privésleutel te bewijzen. Dit proces omvat gecoördineerde acties van zowel Chrome als uw server:

1. Chrome stelt het verzoek van de gebruiker aan uw applicatie uit en stuurt een vernieuwingsverzoek naar /RefreshEndpoint :

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   

2. Uw server reageert met een uitdaging:

   HTTP/1.1 401 Unauthorized
   Sec-Session-Challenge: "challenge_value"
   

3. Chrome ondertekent de uitdaging met de opgeslagen privésleutel en voert het verzoek opnieuw uit:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   Sec-Session-Response: <JWT proof>
   

4. Uw server valideert het ondertekende bewijs en geeft een vernieuwd kortstondig cookie uit:

   HTTP/1.1 200 OK
   
   Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
   

5. Chrome ontvangt de vernieuwde cookie en hervat het oorspronkelijke uitgestelde verzoek.

Alternatief integratiepatroon

Om de veerkracht te verbeteren, kunnen sites naast de kortstondige cookie een tweede, niet-DBSC-cookie toevoegen. Deze cookie met een lange levensduur wordt alleen gebruikt om nieuwe tokens met een korte levensduur uit te geven en helpt onderscheid te maken tussen werkelijk niet-geverifieerde verzoeken en tijdelijke DBSC-fouten.

• De cookie met lange levensduur blijft bestaan, zelfs als DBSC mislukt.
• De kortstondige cookie wordt vernieuwd met behulp van DBSC en is vereist voor gevoelige bewerkingen.

Dit patroon geeft sites meer controle over hoe om te gaan met randgevallen.

Voorbehoud en terugvalgedrag

Chrome kan DBSC-bewerkingen overslaan en verzoeken verzenden zonder de door DBSC beheerde kortstondige cookie in de volgende scenario's:

• Het vernieuwingseindpunt is onbereikbaar vanwege netwerkfouten of serverproblemen.
• De TPM is bezet of ondervindt ondertekeningsfouten. Omdat de TPM wordt gedeeld door systeemprocessen, kunnen excessieve vernieuwingen de snelheidslimieten overschrijden.
• De door de DBSC beheerde kortstondige cookie is een cookie van derden en de gebruiker heeft cookies van derden geblokkeerd in zijn browserinstellingen.

In deze situaties valt Chrome terug op het gebruik van de langlevende cookie als deze nog aanwezig is. Deze fallback werkt alleen als uw implementatie zowel een cookie met een lange levensduur als een cookie met een korte levensduur bevat. Als dit niet het geval is, verzendt Chrome het verzoek zonder cookie.

Samenvatting

Apparaatgebonden sessiereferenties verbeteren de sessiebeveiliging met minimale wijzigingen aan uw applicatie. Ze bieden sterkere bescherming tegen het kapen van sessies door sessies aan specifieke apparaten te koppelen. De meeste gebruikers profiteren hiervan zonder enige verstoring te ervaren, en DBSC valt gracieus terug op niet-ondersteunde hardware.

Raadpleeg de DBSC-specificatie voor meer informatie.