Introduktion til JWT: JSON Web Token (JWT) er en åben standard (RFC 7519), der definerer en kompakt og selvstændig måde at overføre information sikkert mellem parter i JSON-objekter. Disse oplysninger kan verificeres og betros gennem digitale signaturer. JWT'er kan signeres ved hjælp af hemmeligheder (ved hjælp af HMAC-algoritmen) eller ved hjælp af RSAs offentlige/private nøglepar.
Nogle scenarier, hvor JSON Web Tokens er nyttige:
Identitetsverifikation:Dette er det mest almindelige tilfælde af brug af JWT'er. Når brugeren logger ind, vil hver efterfølgende anmodning indeholde en JWT, der giver brugeren adgang til de ruter, tjenester og ressourcer, som tokenet har tilladt. Single sign-on er en funktion, der i dag er udbredt på grund af dens lave overhead og dens evne til nemt at kunne bruges på tværs af forskellige domæner.
Informationsudveksling:JSON Web Tokens er en fremragende måde at overføre information sikkert mellem parter. Fordi JWT'er kan underskrives – for eksempel ved brug af offentlige/private nøglepar – er det muligt at være sikker på, at afsenderen er den, de udgiver sig for at være. Derudover, da signaturen beregnes ved hjælp af headers og payloads, kan du også verificere, at indholdet ikke er blevet manipuleret.
Officiel hjemmeside:Hyperlink-login er synlig.
Parse JWT-information online：Hyperlink-login er synlig.
Analyser JWT-parametre online Hyperlink-login er synlig.
Min forståelse af JWT nedenfor er forkert, giv mig venligst nogle råd
Først og fremmest, det her ting, det anbefales ikke at bruge det på MVC-hjemmesiden, du kan bruge det i webapi, placeringen af dette er API, ikke en session på erstatningswebsitet!
asp.net webapi-brugsvejledning:Hyperlink-login er synlig.Jeg vil ikke lave hjulet om igen, det er okay at se på, hvad denne artikel er skrevet.
Sammensætningen af JWT
JWT består af tre dele: Header, Payload og Signature, med priksymboler imellem for at danne formen xx.yy.zz.
Bemærk, at for signerede tokens kan denne information læses af alle, på trods af manipulationsbeskyttelse. Placer ikke følsomme oplysninger i gyldigt indhold eller header-elementer i JWT, medmindre de er krypteret.
For eksempel:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
alg: "HS256",
typ: "JWT"
}.
{
sub: "1234567890",
name: "John Doe",
iat: 1516239022
}.
[signatur]
På almindeligt dansk kan alle dekryptere dette token, men ægtheden af disse oplysninger kan ikke verificeres; kun den server, der har genereret tokenet, kan verificere ægthedet, så gem ikke følsomme oplysninger i det.
Der er et problem her, nemlig at hvis brugeren ændrer adgangskoden eller brugeren ikke må logge ind, hvordan kan JWT så løse tokenets gyldighed?
Min egen idé er at tilføje en guide-lignende streng i Payload-sektionen, og så eksistere i cachen, når brugerens identitet verificeres, ikke kun verificere jwt'en, men også payload-informationen i jwt'en, kan vi kontrollere gyldigheden ved at kontrollere cachen.
|
Opslået på 21/05/2018 15.56.52
|
|
|
|
Udlejer|
Opslået på 27/04/2021 10.59.48
|
