JWTs

Most vulnerabilities arise due to implementation flaws and/or leaking the sercret key. Our goal is typically to modify the JWT to bypass authentication or impersonate users.

Token Characteristics

Feature	Details
Format	How is it encoded
By value	Contains all the details within it, can be validated by the receiver without calling the AS, can be encrypted/signed
By reference	Random string that acts as a reference to a db entry; only the AS can read it
Purpose	Who is it for
Access token	Resource Server
Refresh token	Authorization Server
ID Token	Client (OpenID Connect)
Type	How can it be used
Bearer	Coin analogy: if you find one you use it wihtout proving that it's yours
/	Credit card analogy: you need proof of ownership to use them (sender-constrained tokens, i.e., bound to a single user)

Figure 1: An example of a Bearer and a DPoP token (image adapted from here).

JSON Web Tokens

JWT is a format that can be used for many purposes, such as ID Tokens (always JWTs), access tokens (can be JWTs), and refresh tokens (almost never JWTs). Most often are signed (JWS), but they can also be encrypted (JWE). They are Base64 encoded, start with ey, and can be decoded using https://jwt.io/ or using jwt_tool.py.

JWTs are a standardized format for sending cryptographically signed JSON data between systems.

• They typically contain claims, i.e., information about users.

• They contain all the data required by a server on the client-side.

Figure 2: Different JWT formats (image adapted from here).

The JWT signature is typically generated by hashing the header and the payload. The resulting hash might be also encrypted. In both cases, the process involves a secret signing key which provides a way for servers to verify that the token data hasn't been tampered with.

Figure 3: The elements of a JWT (image adapted from here).