Introduction to JWT: JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way to securely transfer information between parties in JSON objects. This information can be verified and trusted through digital signatures. JWTs can be signed using secrets (using the HMAC algorithm) or using RSA's public/private key pairs.
Some scenarios where JSON Web Tokens are useful:
Identity Verification:This is the most common case of using JWTs. Once the user logs in, each subsequent request will contain a JWT that allows the user to access the routes, services, and resources allowed by that token. Single sign-on is a feature that is widely used today due to its low overhead and ability to be easily used across different domains.
Information exchange:JSON Web Tokens are a great way to securely transfer information between parties. Because JWTs can be signed - for example using public/private key pairs, it is possible to be sure that the sender is who they claim to be. In addition, since the signature is calculated using headers and payloads, you can also verify that the content has not been tampered with.
Official Website:The hyperlink login is visible.
Parse JWT information online：The hyperlink login is visible.
Analyze JWT parameters online The hyperlink login is visible.
My understanding of JWT below is wrong, please give me some advice
First of all, this thing, it is not recommended for you to use it in the MVC website, you can use it in webapi, the positioning of this thing is API, not a session of the replacement website!
asp.net webapi usage tutorial:The hyperlink login is visible.I won't remake the wheel, looking at what this article is written is okay.
The composition of JWT
JWT is composed of three parts: Header, Payload, and Signature, with dot symbols in between to form the form of xx.yy.zz.
Note that for signed tokens, this information can be read by anyone, despite tampering protection. Do not place sensitive information in the valid content or header elements of the JWT unless encrypted.
For example:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
alg: "HS256",
typ: "JWT"
}.
{
sub: "1234567890",
name: "John Doe",
iat: 1516239022
}.
[signature]
In layman's terms, anyone can decrypt this token, but the authenticity of this information cannot be verified, only the server that generated this token can verify the authenticity, so do not store sensitive information in it.
There is a problem here, that is, if the user changes the password or the user is prohibited from logging in, how can JWT solve the validity of the token?
My own idea is to add a guid-like string in the Payload section, and then exist in the cache, when verifying the user's identity, not only verify the jwt, but also verify the Payload information in the jwt, we can control the validity by controlling the cache.
|
Posted on 5/21/2018 3:56:52 PM
|
|
|
|
Landlord|
Posted on 4/27/2021 10:59:48 AM
|
