JSON Web Token
Last updated
Was this helpful?
Last updated
Was this helpful?
Composed of 3 parts: Header + Payload + Signature
Header is simply a JSON string but it contains information about the algorithm of JWT encryption.
Payload is any data that you want to include into JWT.
Signature is the only part of JWT which is not publicly readable because it is encrypted with a secret key and make sure only specific server can decode the token
It is pieces of information asserted about a subject
There are 2 types of claim - Registered and custom
The JWT specification defines seven reserved claims that are not required, but are recommended to allow interoperability with . These are:
iss (issuer): Issuer of the JWT
sub (subject): Subject of the JWT (the user)
aud (audience): Recipient for which the JWT is intended
exp (expiration time): Time after which the JWT expires
nbf (not before time): Time before which the JWT must not be accepted for processing
iat (issued at time): Time at which the JWT was issued; can be used to determine age of the JWT
jti (JWT ID): Unique identifier; can be used to prevent the JWT from being replayed (allows a token to be used only once)
There are 2 common algorithms to create jwt
It is for symmetric key encryption
A group of algorithms that provide a way of signing messages by means of a shared key.
A simple way for all parties to create and validate JWTs. Any party knowing the key can create new JWTs. In other words, with shared keys, it is possible for party to impersonate another one
It is for asymmetric key encryption
A party uses its private key to sign a JWT. Receivers in turn use the public key (which must be shared in the same way as an HMAC shared key) of that party to verify the JWT. The receiving parties cannot create new JWTs using the public key of the sender.
user enter username and password in frontend and send to backend API end point -> doing auth to see whether username or password is matched with the account data from database -> if matched generate a token with secret key -> send the token to frontend and store into local storage -> after login, front end send token with header bearer authorization to API end point -> doing extraction from bearer authorization header to analysis to the token based on the secret key to get back the user data -> send the user data to front end
Clear the token from local storage and revoke the token from the server
It is a credential used in authentication systems that enables the issuance of new access tokens without requiring the user to re authenticate. It is commonly used in scenarios where long-lived authentication is desired or when access tokens have a limited lifespan
It reduces the risk of exposure of authentication credentials, as access tokens have a shorter lifespan and are more frequently rotated
