Introduktion till JWT: JSON Web Token (JWT) är en öppen standard (RFC 7519) som definierar ett kompakt och självständigt sätt att säkert överföra information mellan parter i JSON-objekt. Denna information kan verifieras och betrodds genom digitala signaturer. JWT kan signeras med hemligheter (med HMAC-algoritmen) eller med RSA:s publika/privata nyckelpar.
Några scenarier där JSON Web Tokens är användbara:
Identitetsverifiering:Detta är det vanligaste fallet med JWT. När användaren loggar in innehåller varje efterföljande förfrågan en JWT som låter användaren komma åt de rutter, tjänster och resurser som tillåts av den token. Single sign-on är en funktion som används i stor utsträckning idag tack vare dess låga overhead och dess enkla användning över olika domäner.
Informationsutbyte:JSON Web Tokens är ett utmärkt sätt att säkert överföra information mellan parter. Eftersom JWT:er kan signeras – till exempel med publika/privata nyckelpar – är det möjligt att vara säker på att avsändaren är den de utger sig för att vara. Dessutom, eftersom signaturen beräknas med hjälp av headers och payloads, kan du också verifiera att innehållet inte har manipulerats.
Officiell webbplats:Inloggningen med hyperlänken är synlig.
Analysera JWT-information online:Inloggningen med hyperlänken är synlig.
Analysera JWT-parametrar online Inloggningen med hyperlänken är synlig.
Min förståelse av JWT nedan är fel, snälla ge mig några råd
För det första, det här är inte rekommenderat att du använder det på MVC:s webbplats, du kan använda det i webapi, positioneringen av detta är API, inte en session av ersättningswebbplatsen!
asp.net handledning för användning av webapi:Inloggningen med hyperlänken är synlig.Jag kommer inte att göra om hjulet, det är okej att titta på vad den här artikeln är skriven.
JWT:s sammansättning
JWT består av tre delar: Header, Payload och Signature, med pricksymboler emellan för att bilda formen xx.yy.zz.
Observera att för signerade tokens kan denna information läsas av vem som helst, trots manipulationsskydd. Placera inte känslig information i giltigt innehåll eller headerelement i JWT om det inte är krypterat.
Till exempel:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
alg: "HS256",
typ: "JWT" }.
{
sub: "1234567890",
name: "John Doe",
iat: 1516239022 }. [signatur] På enkel svenska kan vem som helst dekryptera denna token, men äktheten av denna information kan inte verifieras, endast servern som genererade tokenet kan verifiera äktheten, så lagra inte känslig information i den.
Det finns ett problem här, det vill säga, om användaren ändrar lösenordet eller om användaren förbjuds att logga in, hur kan JWT lösa tokenens giltighet?
Min egen idé är att lägga till en guide-liknande sträng i Payload-sektionen, och sedan finnas i cachen, när man verifierar användarens identitet, inte bara verifiera jwt, utan även verifiera Payload-informationen i jwt, vi kan kontrollera giltigheten genom att kontrollera cachen.
|