1. Introduction

JSON Web Tokens (JWT) are well known to software developers, but JOSE (Javascript Object Signing and Encryption) is rarely known. I first learned about it in the official Documentation for Spring Security, and it changed some of my understanding of JWT. At present, there are not too many relevant Chinese materials available in China. So I think it’s worth generalizing.

2. JOSE overview

JOSE is a set of specifications designed to provide a method for securely transferring claims between parties. The JWT we commonly use contains declarations that allow clients to access specific resources within a specific application. JOSE has developed a series of specifications to achieve this goal. At present, the specification is still in continuous development, we commonly include the following RFCS:

  • JWS (RFC 7515) -JSON Web signature, describing the generation and processing of signature messages
  • JWE (RFC 7516) -JSON Web encryption, which describes protecting and processing encrypted messages
  • JWK (RFC 7517) -JSON Web key, which describes the format and handling of encryption keys in Javascript object signing and encryption
  • JWA (RFC 7518) -JSON Web algorithm that describes encryption algorithms used in Javascript object signing and encryption
  • JWT (RFC 7519) -JSON Web token that describes the representation of a declaration encoded in JSON and protected by JWS or JWE

3. We were all wrong about JWT

Read the description of JWT that says “tokens are represented as JWS or JWE declarations”. Could I have been wrong? After looking for some official materials and studying, IT is true that my previous cognition is not comprehensive enough.

Official definition:

JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties

JSON Web tokens (JWT) are a compact, URL-safe way to represent declarations to be transferred between two parties.

That is, JWT is actually a general term for JOSE handling of declarations. I think we used JWS(JSON Web Signature), which is an implementation of JWT. In addition to JWS, JWT has another implementation, JWE(JSON Web Encryption). The relationship should look like this:

4. What is JWE

We won’t say JWS, it’s what we call JWT. Including the JWT I mentioned in Spring Security actual combat dry goods are ALL JWS. Let’s talk about JWE. The JWS simply signs the claim, ensuring that it cannot be tampered with, but its payload information is exposed. That is, JWS only guarantees data integrity, not data leakage. So I’ve said before that it’s not good for passing sensitive data. JWE came along to solve this problem. See the following figure for details:

As can be seen from the above, the generation of JWE is very tedious and may consume resources and time as a Token. It would be nice to use as a secure data transfer route.

5. Spring Security Jose

You can use the spring-security-oAuth2-Jose class library to use JOSE. If Java developers are going to use OAuth2.0 in the Spring Security framework, this library is also something to look into.

6. Summary

Today we introduced the relatively unfamiliar concept of JOSE and listed several important RFCS in the JOSE specification set. The previous understanding of limitations has also been corrected. It foreshadows our subsequent oAUTH2.0-related learning.

Follow our public id: Felordcn for more information

Personal blog: https://felord.cn