JWT_Presentation to show how jwt is better then session based authorization

Download as PPTX, PDF

0 likes16 views

The document explains JSON Web Tokens (JWT) as a method for secure claims representation between parties, highlighting their structure, including the header, payload, and signature. It discusses the limitations of session-based authentication, emphasizing issues with load balancing and states, and outlines JWT's advantages and security concerns. Additionally, it details scenarios for using JWTs, such as authorization and information exchange, while also noting the importance of expiration to mitigate risks if a token is stolen.

Engineering

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

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 contain all the needed information
for that interaction, nothing is remembered.
No state is maintained over multiple requests.

Session Token:
● In session-based authentication, the server
creates a session for the user after they log in.
The session ID is stored in a cookie on the
user's browser and is sent with every
subsequent request. The server compares the
session ID against the session information
stored in memory to verify the user's identity.

Session Token Problem:
● Modern web apps have multiple servers with
a load balancer deciding which server routes
the request. If a login request happens on
server 1 and the session is stored there, but
the next request goes to server 2, server 2
won't recognize the session ID.

If you can decode JWT, how are they secure?
● JWTs can be signed, encrypted, or both. If a
token is signed but not encrypted, anyone can
read its content, but without the private key,
they can't change it. If tampered with, the
signature won't match.

What happens if your JSON Web Token is
stolen?
● It's bad, really bad. JWTs are used to identify
the client, so if one is stolen, an attacker has
full access to the user's account. However,
JWTs can be configured to expire, making
them slightly less dangerous than stolen
usernames and passwords.

When should you use JSON Web Token?
● Authorization: This is the most common
scenario. Each subsequent request after login
will include the JWT, allowing access to routes,
services, and resources permitted by that token.
● Information Exchange: JWTs are a secure way of
transmitting information between parties. Signed
JWTs can verify the sender's identity.

How does JWT look like?
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlaW
QiOiIzNDc4MzciLCJuYW1lIjoiQWthc2ggTmF0a
CJ9.GfoX38XUi1Eq0YKuUBrh6yGAuin9Z7pLHy
UZNYPtKec

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.

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.

Types of Claims:
● Registered claims: Predefined claims like 'sub'
(subject), 'exp' (expiration time).
● Public claims: Defined by those using JWTs.
They should be unique to avoid collisions.
● Private claims: Custom claims shared between
parties that agree on them.

An example payload could be:
{
"eid": "347837",
"name": "Akash Nath"
}

Signature:
● To create the signature, take the encoded
header, encoded payload, a secret, the
algorithm specified in the header, and sign
that.

JWT_Presentation to show how jwt is better then session based authorization

1. Introduction ● JWT: ● JSON Web Tokens (JWT) are an open, industry standard RFC 7519 method for representing claims securely between two parties.

2. Authorization Strategies ● 1) Session token ● 2) JSON web token

3. 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 contain all the needed information for that interaction, nothing is remembered. No state is maintained over multiple requests.

4. Session Token: ● In session-based authentication, the server creates a session for the user after they log in. The session ID is stored in a cookie on the user's browser and is sent with every subsequent request. The server compares the session ID against the session information stored in memory to verify the user's identity.

5. Session Token Problem: ● Modern web apps have multiple servers with a load balancer deciding which server routes the request. If a login request happens on server 1 and the session is stored there, but the next request goes to server 2, server 2 won't recognize the session ID.

6. If you can decode JWT, how are they secure? ● JWTs can be signed, encrypted, or both. If a token is signed but not encrypted, anyone can read its content, but without the private key, they can't change it. If tampered with, the signature won't match.

7. What happens if your JSON Web Token is stolen? ● It's bad, really bad. JWTs are used to identify the client, so if one is stolen, an attacker has full access to the user's account. However, JWTs can be configured to expire, making them slightly less dangerous than stolen usernames and passwords.

8. When should you use JSON Web Token? ● Authorization: This is the most common scenario. Each subsequent request after login will include the JWT, allowing access to routes, services, and resources permitted by that token. ● Information Exchange: JWTs are a secure way of transmitting information between parties. Signed JWTs can verify the sender's identity.

9. How does JWT look like? eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlaW QiOiIzNDc4MzciLCJuYW1lIjoiQWthc2ggTmF0a CJ9.GfoX38XUi1Eq0YKuUBrh6yGAuin9Z7pLHy UZNYPtKec

10. JSON Web Token Structure: ● 1) Header ● 2) Payload ● 3) Signature

11. 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.

12. 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.

13. Types of Claims: ● Registered claims: Predefined claims like 'sub' (subject), 'exp' (expiration time). ● Public claims: Defined by those using JWTs. They should be unique to avoid collisions. ● Private claims: Custom claims shared between parties that agree on them.

14. An example payload could be: { "eid": "347837", "name": "Akash Nath" }

15. Signature: ● To create the signature, take the encoded header, encoded payload, a secret, the algorithm specified in the header, and sign that.

17. Thank You!

JWT_Presentation to show how jwt is better then session based authorization

More Related Content

Similar to JWT_Presentation to show how jwt is better then session based authorization (20)

Recently uploaded (20)

JWT_Presentation to show how jwt is better then session based authorization