The document discusses JSON Web Tokens (JWT), including how they work and how they provide authorization. It explains that JWTs contain encoded JSON objects with a header, payload, and signature. The payload contains claims about the user's identity. JWTs can be used instead of session tokens to authorize API requests since they allow stateless authentication by including all necessary information in the token itself. The document also discusses potential security issues with JWTs and when they are an appropriate authorization mechanism.
2. Introduction
JWT:
JSON Web Tokens (JWT) are an open, industry standard RFC 7519 method for representing
claims securely between two parties
Authorization strategies:
1) Session token
2) JSON web token
3. Session Token:
In the session based authentication, the server will create a session for the user after the user
logs in. The session id is then stored on a cookie on the user’s browser. While the user stays
logged in, the cookie would be sent along with every subsequent request. The server can then
compare the session id stored on the cookie against the session information stored in the
memory to verify user’s identity and sends response with the corresponding state!
Anyone Authorization mechanism session-based or JWT or any other authorization think in the
future they have one thing to blame that is HTTP.
HTTP:
HTTP is a stateless protocol. This means a HTTP server needs not keep track of any state
information. So, every Interaction in HTTP needs to contains all the needed information for that
interaction, nothing is remembered. No state is maintained over like multiple requests.
5. Session Token Problem:
Modern web app has multiple servers and has load balancer to decide which server to route the
request. Let suppose so the server could have a login request in server 1 and the session in the
memory is server-1 the next request goes throw the load balance in server-2 now server-2 is no
idea about the previous exchanges. Only server-1 is recognized the id token.
7. If you can decode JWT, how are they secure ?
JWTs can be either signed, encrypted or both. If a token is signed, but not encrypted, everyone
can read its content, but when you don’t know the private key, you can’t change it. otherwise, the
receiver will notice that the signature won’t match anymore.
8. What happen if your json web token is stolen?
It’s a bad real bad.
Because JWT are use to identify the client , if one is stolen , an attacker has full access to the
user’s account information.
If attacker get a hold of your JWT they could start sending request to the server identifying
himself as you and do thing like make service changes , user account update etc.
Once an attacker has your JWT it is game over.
But there is one thing that make a stolen JWT slightly less bad than a stolen username and
password: timing. Because JWT can be configured to automatically expire after a set of amount
attacker only use your JWT to access the service until it expire.
One of the ways token authentication is said to make authentication more “secure” is via
short-lived token.
9. When should you use JSON web token?
● Authorization: This is the most common scenario for using JWT. once the user is logged in,
each subsequent request will include the JWT, allowing to user the access routes, services,
and resources that are permitted with that token.
● Information Exchange: JSON Web Tokens are a good way of securely transmitting
information between parties. Because JWT can be signed- for example using
public/private key pairs- you can be sure the sender who they say they are.
12. JSON Web Token structure:
1) Header
2) Payload
3) Signature
HEADER:
The header typically consists of two parts: the type of the token, which is JWT, and the signing
algorithm being used, such as HMAC, SHA256 or RSA.
13. Payload:
The second part of the token is the payload, which contains the claims. Claims are statements
about an entity (typically, the user) and additional data.
There are three types of claims:
● Registered
● Public
● Private claims.
Registered claims:
These are the set of predefined claims which are not mandatory but recommended, to
provide a set of useful, interoperable claims. Example sub(subject), exp(expiration time) and
others.
14. Public claims:
These can be defined at will by those using JWTs. But to avoid collision they should be defined
in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant
namespace.
Private claims:
These are the custom claims created to share information between parties that agree on
using them and are neither registered or public claims.
An example payload could be:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
15. Signature:
●To create the signature part you have to take the encoded header, the encoded payload, a
secret, the algorithm specified in the header, and sign that.