JSON WEB TOKEN
2 likes1,089 views
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.
JSON WEB TOKEN
- 1. Presented By: Sumit JSON WEB TOKEN
- 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.
- 10. How does JWT look like?
- 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.
- 17. Thank You !