# JSON Web Token

## Structure

![](https://1374779285-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFW3x2aqEO8GF2kr3VU%2Fuploads%2FPMtJ3ar94P9X6yj0YmiJ%2Fscreenshot-www.udemy.com-2022.11.14-12_57_00.png?alt=media\&token=0983518c-7e48-4a1b-b219-8f85a42a6255)

![](https://1374779285-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFW3x2aqEO8GF2kr3VU%2Fuploads%2FrXpTI0aZcTXYKb5THGm9%2Fscreenshot-www.udemy.com-2022.11.14-12_57_52.png?alt=media\&token=dcf2cade-e4a3-48c1-8139-196a80a60f60)

* 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

## Claim

* 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 [third-party applications](https://auth0.com/docs/get-started/applications/confidential-and-public-applications/enable-third-party-applications). 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)

## Signing & Verify

* There are 2 common algorithms to create jwt

### HMAC

* It is for symmetric key encryption&#x20;
* 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

### RSA

* It is for asymmetric key encryption&#x20;
* 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.

## Flow

![螢幕截圖 2020-08-24 下午4 40 43](https://user-images.githubusercontent.com/46919822/91024090-04b1d680-e62a-11ea-96e3-0a4ef845932c.png)

### Login

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

### Logout

* Clear the token from local storage and revoke the token from the server

## Refresh Token

* 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

