Introduction to JWT. IO/Introductio…

What is JSON Web Token (JWT)?

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and independent way to securely transfer information between parties as JSON objects. This information can be authenticated and trusted with a digital signature. JWT can sign using secret (using the HMAC algorithm) or using RSA or ECDSA’s public/private key pair. While JWT can be encrypted to provide confidentiality between parties, it will only focus on signing tokens. A signed token verifies the integrity of the declarations contained therein, while an encrypted token hides the declarations of other parties. When a token is signed using a public/private key pair, the signature also proves that only the party holding the private key is the party signing the private key.

Generally speaking, JWT is an encrypted string containing a signature and carrying user information. When a page requests to verify the login interface, the JWT string is carried in the request header to the back-end service, which ensures that the information is not tampered through the signature encryption string matching verification. If the verification passes, it is considered a reliable request and data is returned normally.

Ii. When is JWT appropriate?

Authorization: This is the most common scenario used to solve single sign-on problems. JWT is widely used because it is light and inexpensive to use, and the server does not record user status information (stateless).

Information exchange: JWT is a good way to securely transfer information between services. Because JWT can sign, for example, using a public/private key pair – you can be sure the requester is legitimate. In addition, because the header and payload are used to compute the signature, you can verify that the content has not been tampered with.

Iii. What is the structure of JWT?

JWT consists of three parts: header information, payload, and signature

In the middle is (.) Delimit, in the following format:

    xxxxx.yyyyy.zzzzz
Copy the code

Header information

It consists of two parts, token type (i.e., JWT), hash algorithm (HMAC, RSASSA, rsASSa-PSS, etc.), for example:

{
  "alg": "HS256",
  "type": "JWT"
}
Copy the code

This JSON is then encoded as Base64Url to form the first part of the JWT.

It’s a Payload.

The second part of the JWT is payload, which contains claims. Claims are claims about entities (commonly user information) and other data. There are three types of claims: registered, public, and private claims.

Registered Claims: These are a set of predefined claims, optional but recommended, ISS (issuer), EXP (due time), SUB (subject), AUD (audience), etc.;

Public Claims: Custom claims that do not conflict with attributes in the JWT registry, which can be viewed here

Private Claims: These are custom claims that are used to share information between parties agreeing to use these claims. They are neither Registered claims nor Public claims.

Here is an example of payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}
Copy the code

Then, Base64Url encoding is used to form the second part of JWT.

Note: For signed tokens, this information, while tamper-proof, can be read by anyone. Do not put sensitive information in the Payload or Header element unless it is encrypted.

Signature

To create a signed part, you must take the encoded Header, the encoded Payload, the secret key, the algorithm specified in the Header, and sign it. For example, if you want to use the HMAC SHA256 algorithm, you create a signature as follows:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)
Copy the code

The signature is used to verify that the message has not been tampered with in the process, and, in the case of signing the token with the private key, to verify that the requester of JWT is the requester it claims to be.

The output is three dot-separated Base64-URL strings that can be passed easily in HTML and HTTP environments and are more compact than XML-based standards such as SAML.

  

How does JWT work?

In authentication, a JSON Web Token (that is, JWT) is returned when the user successfully logs in with his credentials. Because tokens are credentials, great care must be taken to prevent security issues. In general, tokens should not be retained for longer than required. In theory, the shorter the timeout, the better.

Whenever a user wants to access a protected route or resource, the user agent should send a JWT using Bearer mode, usually in an Authorization header. The title should read as follows:

    Authorization: Bearer <token>
Copy the code

In some cases, this can be used as a stateless authorization mechanism. The server’s protected route checks the valid JWT in the Authorization header and, if valid, allows the user to access the protected resource. If the JWT contains the necessary data, you can reduce querying database or cache information. If the token is sent in the Authorization header, cross-domain resource sharing (CORS) will not be an issue because it does not use cookies.

Note: With signed tokens, although they cannot be changed, all information contained in the token is made public to the user or other parties. This means that sensitive information should not be placed in the token.

What are the benefits of using JWT?

Compared with Simple Web Tokens (SWT) and Security Assertion Markup Language Tokens (SAML);

JWT is more compact than SAML and delivers more easily in HTML and HTTP environments; In terms of security, SWT can only use the HMAC algorithm to symmetrically sign through the shared key. However, JWT and SAML tokens can be signed using public/private key pairs in the form of X.509 certificates. Compared to the simplicity of signing JSON, using XML digital signatures can have security vulnerabilities; JSON parsing into objects is more popular and convenient than XML.