Skip to content

Latest commit

 

History

History
60 lines (39 loc) · 3.6 KB

jwt.md

File metadata and controls

60 lines (39 loc) · 3.6 KB

About Json Web Token

Stateless application

Stateless applications do not store any state in memory, the application do not have session ! This kind of applications became very popular because they have some advantage for cloud architectures :

  • No session means there is session's leaks ... on server side ಠ_ಠ It comes with new risk on client side. We will see how to mitigate them later.
  • Ease for horizontal scaling : the instance whom is reached by a request doesn't matter

Except for Create Read Update Delete (CRUD) applications, we often need some kind of session. To be honest Stateless app are rarely stateless (⊙_⊙')

Stateless means that applications do not store any state in memory: you got it? (°o•)

So sessions are managed as an API (like database) and we use Key/Value (i.e., Irmin, Redis, rocksDB, levelDB, ...) database in fact to manage sessions accross instances.

Json Web Token

JWT is an open standard RFC 7519 that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

A common usage of JWT is authentication to stateless services :

  1. A token that is issued by the server.
  2. The token has a JSON payload that contains information specific to the user.
  3. This token can be used by clients when talking to APIs (by sending it along as an HTTP header) so that the APIs can identify the user represented by the token, and take user specific action.

The JWT also contains a signature. This signature is created by the server that issued the token (let’s say your login endpoint) and any other server that receives this token can independently verify the signature to ensure that the JSON payload was not tampered with.

A JWT looks something like this, when it's serialized: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaXNzIjoiYXV0aC5vcnl4LnJvY2tzIiwiaWF0IjoxNjA2MDM4MDExLCJleHAiOjE2MDY3NDgwMTF9.IgpyPIP1A0Xz3MgZAOWJfS90Q34SMLtF63oank9afMI

If you decode that base64 on jwt.io, you'll get JSON in 3 important parts: , payload and signature.

  • Header: consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA. For exemple:
{
  "alg": "HS256",
  "typ": "JWT"
}
  • Payload: contains the claims. Claims are statements about an entity (typically, the user) and additional data. There is 3 types of claims: reserved, public and private. For exemple:
{
  "sub": "1234567890",
  "name": "John Doe",
  "iss": "auth.oryx.rocks",
  "iat": 1606038011,
  "exp": 1606748011
}
  • Signature: Generated by hash algorithm applyed to the encoded header and the encoded payload with a secret. For exemple: try our previous token on jwt debugger. Do you notice the Invalid Signature error ? Then type miage in the secret field and paste our token again.

signature

A JWT is not encrypted. It is based64 encoded and signed. So anyone can decode the token and use its data. A JWT's signature is used to verify that it is in fact from a legitimate source.