JWT is an open standard (RFC 7519) that defines a way of data using a JSON object. It is used primarily for authentication and authorization. Tokens are mostly created using a secret or private/public key. I write "for the most part" because it can happen that JWT does not have a signature. In that case, we talk about "unsecured JWT".
Ok, but what is the said signature? Let's start with the fact that our JSON Web Token consists of three parts. These include:
- header
- payload
- signature
Each part is separated by a dot, and a sample token might look like the following.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkJ1Z3NwYWNlIiwiaWF0IjoxNTE2MjM5MDIyfQ.04eZFycQi8uO0HAhAiejW6id0MBbM34PTNXsb6WQr6Y
After changing from an encrypted record to a JSON object:
{
"alg": "HS256",
"typ": "JWT"
}.{
"sub": "1234567890",
"name": "Bugspace",
"iat": 1516239022
}.HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
28BCCC274AD2F9EEDC51C3FCC33A1
)
Header
{
"alg": "HS256",
"typ": "JWT"
}
It contains information about the algorithm used and the type of token. The most commonly used cryptographic algorithms include HMAC with SHA-256 (HS256) and RSA signature with SHA-256 (RS256). JWT is not limited and it is possible to use other types of algorithms. These are available at this link.
Payload
{
"sub": "1234567890",
"name": "Bugspace",
"iat": 1516239022
}
The part of the JWT responsible for storing the data sent to the server. It places, for example, information about the expiration date of the token or the user's role on the site. Both the payload and the header are encoded in Base64 format.
Signature
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
28BCCC274AD2F9EEDC51C3FCC33A1
)
The last element that makes up the construction of the JWT is the signature, designed to confirm the authenticity of the token being sent. Assuming that we use the HMAC SHA256 algorithm for hashing, our signature will be created based on the following code.
signature = HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)
What this means for us is that without knowing the secret, any change to the token will be unauthorized. We will not be able, for example, to change the user privileges in our payload.
Security flaws
However, the use of JWT comes with certain limitations and, as in any case, a number of vulnerabilities. Among the most important problems are the possibility of cracking the HS256 algorithm (HMAC-SHA256), the potential problem of implementation with an asymmetric algorithm such as RS256, or over-compilation caused by the multiplicity of algorithms, among others. About these and related topics exhausting the issue of JWT, we refer you to ebook from sekurak and blog describing the min. vulnerabilities described above.
Sources
https://jwt.io/
https://tools.ietf.org/html/rfc7518
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
https://sekurak.pl/jwt-security-ebook.pdf
Top comments (0)