JWT, JWS, JWE, JWA, and JWK

1. Overview

• JWT is used to transport user identity/entitlements between interested parties in a secure manner.
• JWS and JWE are instances of the JWT when used compact serialization
• JWS and JWE can be serialized using either the compact serialization or JSON serialization
• JWT doesn't' define a specific binding, but in practice, JWT tokens are transported over HTTPS under the Authorization Bearer header, just as in OAuth 2.0

1.1 Benefit of JWT

1.1.1 More Compact

As JSON is less verbose than XML, when it is encoded its size is also smaller, making JWT more compact than SAML. This makes JWT a good choice to be passed in HTML and HTTP environments.

1.1.2 More Secure

Security-wise, SWT can only be symmetrically signed by a shared secret using the HMAC algorithm. However, JWT and SAML tokens can use a public/private key pair in the form of a X.509 certificate for signing. Signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to the simplicity of signing JSON.

1.1.3 More Common

JSON parsers are common in most programming languages because they map directly to objects. Conversely, XML doesn't have a natural document-to-object mapping. This makes it easier to work with JWT than SAML assertions.

1.1.4 Easier to process

Regarding usage, JWT is used at Internet scale. This highlights the ease of client-side processing of the JSON Web token on multiple platforms, especially mobile.

2. Motivation

2.1 Server-based authentication

In the existing authentication system, the user information must be stored on the server-side. Several methods are used to maintain this session. It's often stored in a memory/disk/database system.

2.2 Limitation of Server-based authentication

2.2.1 Session

When the user authenticates, the server must store this record on the server. This is called a session. In most cases it is stored in memory, but what if the number of users logging in increases? Will the server RAM be overloaded? To avoid this, there is also a way to store sessions in the database on the system, but this can also affect the performance of the database if the number of users is large.

2.2.2 Scalability

Using a session makes it difficult to scale the server. Here, server expansion means not just upgrading the server's specifications, but running multiple processes or adding multiple server computers to handle more traffic. Designing a distributed system using sessions is not impossible, but the process is very complicated.

2.2.3 Cross-Origin Resource Sharing(CORS)

Cookies that are frequently used when managing sessions in web applications are designed to work only in a single domain and subdomain. Therefore, managing cookies in multiple domains is a bit cumbersome.

2.3 How token-based systems work

Token-based systems are stateless. Stateless. In other words, it does not maintain state. The user's authentication information is no longer stored in the server or session in this system. With this concept alone, many problems caused by storing the user's authentication information on the server described above on the server-side are solved.

Since the session doesn't exist, users can easily expand the server without worrying about whether they are logged in or not.

The implementation method of the token-based system may vary greatly from system to system, but at a glance:

1. User logs in with ID and password
2. The server side verifies the account information.
3. If the account information is correct, the server issues a signed token to the user.
4. The meaning of signed here is that it has a signature that proves that the token is normally issued by the server.
5. The token received from the client is stored, and whenever a request is made to the server, the token is transmitted to the server.
6. The server verifies the token and responds to the request.

When the webserver passes the token to the server, it is sent by including the token value in the header of the HTTP request.

2.4 Advantages of token

2.4.1 It is stateless and has scalability

Since the token is stored on the client-side, it is completely stateless and provides a very suitable environment for expanding the server. If you are storing sessions on the server-side and distributing requests using multiple servers, when a user logs in, that user should be configured to send requests only to the server on which he first logged in. However, if you use tokens, it doesn't matter what server the request comes from.

2.4.2 Security

When a client sends a request to the server, the vulnerability caused by the use of cookies by eliminating the delivery of cookies is eliminated. However, vulnerabilities may exist in an environment where tokens are used, so always be prepared for them.

2.4.3 Extensibility

Extensibility is another concept here. Scalability means expanding the server, while Extensibility means expanding the field where login information is used. You can also use tokens to share your rights in other services. For example, in the startup job search web service Rocket Punch, you can log in with your Facebook, LinkedIn, GitHub, and Google accounts. In a token-based system, you can issue tokens with selective privileges (for example, if you log in to your Facebook account from Rocket Punch, you have the right to get profile information, but the right to write posts)

2.4.4 Multiple platforms and domains

Did you mention CORS when dealing with problems with server-based authentication systems? As the size of applications and services grows, we make multiple devices compatible and provide more types of services. If a token is used, the request will be processed normally if the token is valid on any device, on any domain. On the server-side, you only need to include the following header in the response part of the application.

Access-Control-Allow-Origin: *

With this structure, assets files (images, CSS, js, HTML files, etc.) can all be provided by CDN, and the server-side can be designed to handle only the API.

2.4.5 Based on web standards

JWT, the implementation of the token-based authentication system, is registered to the web standard RFC 7519. Therefore, it is supported in various environments (.NET, Ruby, Java, Node.js, Python, PHP, etc.) and is used in the infrastructure of numerous companies (Google, Microsoft, and etc.)

3. JSON Web Token (JWT)

• It became an IETF standard in May 2015 with the RFC 7519
• Defines a container to transport data between interested parties
• JWT does not exist itself — either it has to be a JWS or a JWE (JSON Web Encryption).
• It's like an abstract class — the JWS and JWE are the concrete implementations.
• Consisted of 3 parts

2.1 Javascript Object Signing and Encryption (JOSE) Header

• The first part of the JWT is known as the JOSE header
• Stands for Javascript Object Signing and Encryption
• The JWT specification only defines two elements (typ and cty) in the JOSE header

2.1.1 Media Type (typ)

• The typ element is used to define the media type of the complete JWT. It is an identifier, which defines the format of the content, transmitted on the Internet.
• Helps JWT applications to differentiate the content of the JWT when the values that are not JWTs could also be present in an application data structure along with a JWT object

2.1.2 content type (cty)

• Used to define the structural information about the JWT
• Recommended to use this element in the case of a nested JWT

• Unsecured JWT
  • Unsecured JWT is a JWS object wherein the JOSE header the value of the alg element is set to none
  • A JWS without a signature
  • Expected that the underlying transport will provide a guarantee on the integrity and the confidentiality of the token like TLS

2.2 Signature

The third part of the JWT is the signature

2.3 Serialization

• JWS/JWE compact serialization
• JWS/JWE JSON serialization

2.4 Claim Set

• It's JWS payload
• The second part of the JWT is known as the JWT claim set.
• Represents JSON object
• Each claim name within a JWT must be unique
• It's up to each application of JWT to define mandatory and optional claims

2.5 Two types of components that process a JWT

2.5.1 JWT implementations

• Nimbus is a JWT implementation in Java

2.5.2 JWT applications

• Can be anything, which uses JWTs internally
• Using JWT implementation to build or parse a JWT

3. JSON Web Signature (JWS)

• A signed JWT
• Both the alg and kid elements in JOSE header, are not defined in the JWT specification
• Extends typ and cty to add appropriate elements
  • JWS Compact Serialization
  • JWS JSON Serialization

3.1 JWS Compact Serialization

JWS compact serialization represents a signed JWT as a compact URL-safe string. This compact string has three main elements separated by periods (.): the JOSE header, the JWS Payload and the JWS signature. If you use compact serialization against a JSON payload (or any payload — even XML), then you can have only a single signature, which is computed over the complete JOSE header and JWS payload.

3.2 JWS JSON Serialization

The ultimate serialized form under JWS JSON serialization wraps the signed payload in a JSON object, with all the related metadata. This JSON object includes 2 top-level elements: payload and signatures (which is a JSON array), and three sub-elements under each entry of the signatures array: protected, header and signature.

 

4. JSON Web Encryption (JWE)

• Standardizes the way to represent an encrypted content in a JSON-based data structure
• The message to be encrypted using JWE standard needs not to be a JSON, the payload can be any content
• Defines two serialized forms to represent the encrypted data structure
  • JWE compact serialization
  • JWE JSON serialization
• Extends typ and cty to add appropriate elements

4.1 JWE Compact Serialization

With the JWE compact serialization, a JWE token is built with five key components, each separated by a period (.): JOSE header, JWE Encrypted Key, JWE initialization vector, JWE Additional Authentication Data (AAD), JWE Ciphertext and JWE Authentication Tag.

4.2 JWE JSON Serialization

The ultimate serialized form under JWE JSON serialization represents an encrypted payload in a JSON object. This JSON object includes six top-level elements: protected, unprotected, recipients, iv, ciphertext and tag. Following is an example of a JWE token, which is serialized under JWE JSON serialization.

5. JWT Bindings

It defines how to transport the token from one place to another. JWT doesn't have a standard binding. But in most of the cases, The JWT is transported over HTTP under the Authorization Bearer header(like in OAuth 2.0)

Authorization: Bearer <jwt-token>

A bearer token means, whoever owns the token can use it without proving the ownership of the token.  Its like cash. If someone steals a bearer token he can just use it as the legitimate owner of it. So using a bearer token, it has to be done over a secure medium like TLS.

6. JSON Web Key (JWK)

A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.

Whether we're handling signed or encrypted JWTs, we need formal guidelines to be able to transmit public keys efficiently. This is the purpose of JWK, a JSON structure that represents a cryptographic key, defined also by the IETF. With it, other applications can find information on public keys to process JWTs. For instance, a Resource Server uses the kid (Key Id) field present in the JWT to find the correct key in the JWK Set.

7. JSON Web Algorithm (JWA)

This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. 

7.1 Cryptographic Algorithms for JWS

Alg Parameter Value	Algorithm
HS256	HMAC using SHA-256 hash algorithm
HS384	HMAC using SHA-384 hash algorithm
HS512	HMAC using SHA-512 hash algorithm
RS256	RSA using SHA-256 hash algorithm
RS384	RSA using SHA-384 hash algorithm
RS512	RSA using SHA-512 hash algorithm
ES256	ECDSA using P-256 curve and SHA-256 hash algorithm
ES384	ECDSA using P-384 curve and SHA-384 hash algorithm
ES512	ECDSA using P-521 curve and SHA-512 hash algorithm

7.2 Cryptographic Algorithms for JWE

7.2.1 Algorithm (alg) Paramter Values

 

alg Parameter Value	Encryption Algorithm
RSA1_5	RSA using RSA-PKCS1-1.5 padding, as defined in RFC 3447 [RFC3447]
RSA-OAEP	RSA using Optimal Asymmetric Encryption Padding (OAEP), as defined in RFC 3447 [RFC3447]
ECDH-ES	Elliptic Curve Diffie-Hellman Ephemeral Static, as defined in RFC 6090 [RFC6090], and using the Concat KDF, as defined in [NIST‑800‑56A], where the Digest Method is SHA-256
A128KW	Advanced Encryption Standard (AES) Key Wrap Algorithm using 128 bit keys, as defined in RFC 3394 [RFC3394]
A256KW	Advanced Encryption Standard (AES) Key Wrap Algorithm using 256 bit keys, as defined in RFC 3394 [RFC3394]
A128GCM	Advanced Encryption Standard (AES) using 128 bit keys in Galois/Counter Mode, as defined in [FIPS‑197] and [NIST‑800‑38D]
A256GCM	Advanced Encryption Standard (AES) using 256 bit keys in Galois/Counter Mode, as defined in [FIPS‑197] and [NIST‑800‑38D]

7.2.2 Encryption Method (enc) Parameter Values

enc Parameter Value	Symmetric Encryption Algorithm
A128CBC	Advanced Encryption Standard (AES) using 128 bit keys in Cipher Block Chaining mode, as defined in [FIPS‑197] and [NIST‑800‑38A]
A256CBC	Advanced Encryption Standard (AES) using 256 bit keys in Cipher Block Chaining mode, as defined in [FIPS‑197] and [NIST‑800‑38A]
A128GCM	Advanced Encryption Standard (AES) using 128 bit keys in Galois/Counter Mode, as defined in [FIPS‑197] and [NIST‑800‑38D]
A256GCM	Advanced Encryption Standard (AES) using 256 bit keys in Galois/Counter Mode, as defined in [FIPS‑197] and [NIST‑800‑38D]

8. Process

• Register Clients in an Authorization Server - either in our own service, or in a well-known provider like Okta, Facebook, or Github.
• These Clients will request an access token from the Authorization Server. following any of the OAuth strategies we might have configured
• They will then try to access the resource presenting the token (in this case, as a JWT) to the Resource Server
• The Resource Server has to verify that the token hasn't been manipulated by checking its signature as well as validate its claims
• And finally, our Resource Server retrieves the resource, now being sure that the Client has the correct permissions.

9. References

https://velopert.com/2389

https://jwt.io/introduction/

https://velopert.com/2350

https://www.baeldung.com/spring-security-oauth-jwt

https://www.baeldung.com/rest-api-spring-oauth2-angular

https://dzone.com/articles/oauth-20-beginners-guide

https://www.baeldung.com/spring-security-oauth2-jws-jwk

https://tools.ietf.org/html/rfc7515

https://tools.ietf.org/html/rfc7519

https://tools.ietf.org/html/rfc7517

https://tools.ietf.org/html/rfc7518

https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3

https://www.slideshare.net/kura_lab/overview-of-json-object-signing-and-encryption

http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-00.html