JWT can be represented by JWS or JWE, I’ll cover this aspect in more detail later.
JSON Web Signature, content protected using digital signature techniques or message authentication code techniques (MAC) based on JSON data structures can be referred to as JWS. The cryptographic algorithms and identifiers used in this specification are defined in a separate specification JWA. The rules are more see RFC7515, here we just go through the serialization to get a feel for it.
The serialization of JWS is divided into JWS Compact Serialization and JWS JSON Serialization.
JWS Compact Serialization
This serialization is represented as a URL-safe, compact string. The format is.
JWT is usually this format.
JWS JSON Serialization
This serialization is represented as a JSON object and comes in two formats. The general format is.
The tiled format is
As an example of a general format.
JWS only signs the claims to ensure that they are not tampered with, but the payload information is exposed. That is, JWS only guarantees the integrity of the data but not its non-disclosure. It is not suitable for passing sensitive data. JWE was created to solve this problem. The details can be seen in the following figure.
As you can see from the above JWE is very tedious to generate and may be resource and time consuming as a Token. It should be good to use as a secure data transfer path. As an example.
There are five parts in total, separated by four English periods.
Actually, JWE also has a corresponding JSON format with the same two serialization methods of JWS, see RFC7516.
Relationship of JWT to JWS and JWE
The following is a description of JWT from RFC7519.
Some conclusions can be drawn from the above.
JWT has specific
claimswhich are composed of
Payloadin the form of JSON.
JWT can be structured as JWS or JWE.
JWT can only be serialized using Compact Serialization, not JSON Serialization.
In short, JWT is a JWS or JWE string that contains specific
claims. Most of our common ones are JWS.
Also, we usually read
T, and actually recommend to read
jot(corner special), see RFC7519 for the definition and specification of JWT.
JWK is the most important point of knowledge in this article, which is important for us to learn about the Resource Server** later.
I believe Signing Public and Private Keys is not new to anyone. The JWT itself has to be signed with a private key to prevent information tampering, and the public key is used to send to the downstream consumer to verify the reliability of the JWT. Usually, the public key is configured in a static file integration, which has the disadvantage that when the upstream public and private keys are changed, the downstream cannot dynamically adapt the public key. This is the problem that JWK has to solve, with its canonical design of cryptographic algorithms and identifiers, and its compact JSON data structure is very easy to transfer between upstream and downstream.
JWK is a JSON object that represents the encryption key. The object contains a
key name that must be unique, on top of which JWK can contain some custom fields. The following is a JWK representation of a P-256 EC (Elliptic Curve Discrete Cipher) key.
As defined in RFC7517, a JWK JSON object may contain the following attributes.
Depending on the algorithm JWK may also contain other properties.
A JWK Set represents a set of JWK with different
kids, which is very easy to understand. It is also a JSON object, and the only
keys. As an example.
The JWK Set URL in the > OAuth2 configuration is the endpoint to output the JWK Set.
The JWA specification specifies which algorithms can be used as cryptographic algorithms for JWS and JWE. It also specifies the
alg properties in JWK corresponding to these algorithms, as well as the properties that specific algorithms include in JWK such as
y in the previous EC algorithm, which are not set in stone, they are adjusted based on the iteration of the algorithm. If you are interested in the details of JWA, see RFC7518.
You can generate JWK by yourself using some algorithms via the JWK generator to observe the differences between the different algorithms.
Today’s brief introduction to the JOSE specification is very helpful for you to learn about OAuth2 and OIDC related knowledge. It is not required to go deep but must understand the relevant knowledge.