Introduction:
Web authentication relied on cookies or sessions to authenticate users to web applications. These methods were good but had some drawbacks :
- Scalability,
- Storage limitations,
- Difficulty in integrating with third-party services
JWT solved these issues by providing a simple, secure, and flexible way to authenticate users in web applications. Lets discuss first what is JWT?
As per https://jwt.io/
"JSON Web Tokens(JWT) are an open, industry standard RFC 7519 method for representing claims securely between two parties."
It is self-contained method for securely transmitting information between parties as a JSON object. JWTs are a good way of securely transmitting information between parties because they can be signed, which means you can be certain that the senders are who they say they are.
Anatomy of a JWT:
A JSON Web Token is essentially a long encoded text string. This string is composed of three smaller parts, separated by a dot sign. These parts are:
- Header
- Payload/Body
- Signature
 |
| Anatomy of JWT |
Header:
The header contains metadata about the token. It has 2 parts:
type- JWT
algo- cryptographic algorithm used to sign it.
{
"alg": "HS256",
"typ": "JWT"
}Encoing format: encoded in Base64Url format.
Payload:
The payload contains the claims or information about the user. Claims are statements about an entity (typically, the user) and additional data.
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
Encoing format: encoded in Base64Url format.
Signature:
The signature is used to verify the integrity of the message and to ensure that it has not been tampered with. The signature is created by encoding the header and payload, concatenating them with a dot, and then signing the resulting string with a secret key using a cryptographic algorithm such as HMAC or RSA.
 |
JWT Structure |
JWT: <header>.<body>.<signature>
JWT claim Convention:
You may have noticed that in the JWT (that is issued by Google) example above, the JSON payload has non-obvious field names. They use sub, iat, aud and so on:
- iss: The issuer of the token (in this case Google)
- azp and aud: Client IDs issued by Google for your application. This way, Google knows which website is trying to use its sign in service, and the website knows that the JWT was issued specifically for them.
- sub: The end user’s Google user ID
- at_hash: The hash of the access token. The OAuth access token is different from the JWT in the sense that it’s an opaque token. The access token’s purpose is so that the client application can query Google to ask for more information about the signed in user.
- email: The end user’s email ID
- email_verified: Whether or not the user has verified their email.
- iat: The time (in milliseconds since epoch) the JWT was created
- exp: The time (in milliseconds since epoch) the JWT was created
- nonce: Can be used by the client application to prevent replay attacks.
- hd: The hosted G Suite domain of the user
JWT Authentication Flow:
 |
| JWT Authentication Flow |
Why we need JWT?
- Secure: JWT is cryptographically signed, making it difficult to tamper with the token.
- Stateless: JWT is stateless, meaning the server does not need to keep track of the user’s session. This makes it more scalable and less storage-intensive.
- Third-party Integration: JWT can be easily integrated with third-party services like OAuth and OpenID Connect.
- Cross-Domain: JWT can be used for cross-domain authentication because it can be sent as a HTTP Authorization header.
How do they work (using an example) ? Refer here
Happy coding!
No comments:
Post a Comment