Authorization Strategies
HTTP is a stateless protocol that's why we need to send all the desired information each time, so that the server can authorize the request.
Let's say you are logged in tinder, while login you need to enter your user name and password. Tinder will verify if you are a valid user or not, if yes, it will start showing potential matches. Now if you right or left swipe on any profile, or do anything else on Tinder, it will send a request again to the Tinder server. Since HTTP is stateless, with each request you will asked to enter your credentials, which is quite irritating. To solve this problem, the session is managed.
Two of the popular ways to manage session is by using a session token or a JSON web token. After successful login, Tinder will provide some kind of token, which will be stored on client side and will be sent with subsequent requests for the authorization purpose.
Let's understand both the tokens with the help of an example.
Example of session token
Suppose a customer calls a customer support desk to raise a concern. The customer support executive creates a ticket, which will be stored in the database. He/She then provides the complaint number to the customer and tell the customer to call again tomorrow.
The customer saves the complaint no. and call again, some other customer case executive picks up the call. The customer gives the complaint number, and the executive checks the status provide updates to the user. Imagine, if we do not provide the complaint number to the customer and store the customer issues in the database, the customer has to again tell the whole story. A session token works in a similar way.
Whenever user log's in the any application, server will verify the credentials, generate the session token, store it in the database and gives the session token to the user. The user (which may be a browser or an app) stores that session token in a cookie and send it to the server with each request. The server will verify the session token before processing any request.
Problem with session token
When we are using session token, we assume there is only one monolithic server which handles each request. But in real life, there will be n number of servers, and each request will reach the server via a load balancer.
Now lets say server 1 has generated the session token, which is returned to the client. Next time when the request is received, the load balancer my send the request (with valid session token) to some different server. This server does not have the session details, hence the user request will be rejected. To resolve this we can use shared cache (e.g redis), which will have information related to each session token. All the servers will validate the token from this shared cache. The drawback is that if this shared cache goes down it will have an impact on all the servers.
To resolve this, we can make sure the load balancer to send all the subsequent requests to the server which had generated the session token. But again this is practically not possible, because when we are using micro services, its not necessary that each service is deployed on same server.
Example of JSON web token
Let's say a patient went to visit a doctor, after examining doctor prescribed some medicines and hand over the prescription along with the report to the patient.
Next time when the patient visits the doctor, he/she carry the documents. Doctor will check the previous report and prescription, before doing the examination again. If the documents are missing, the doctor will request the patient to tell the problems again. Since the patient has the previous documents, he/she doesn't need to tell the whole story again (i.e authorization is not required).
Anyone can make such (fake) documents and visit the doctor, that's why for the verification purpose, the doctor hand over the report to the patient after stamping. Next time the patient visit the doctor, before checking the report doctor will check if the report is stamped or not? If yes, then only the doctor will proceed further.
This signed document is same as JWT web token.
When you login in Tinder, the tinder server will return a JWT token (which is signed). In the subsequent request the browser or app will send this JWT token, tinder server will first check token (by verifying the signature) and then process the request.
Problem with JWT token
In case of JWT, the communication for the verification happens between a client and server only, the information related to JWT token is not stored in DB. What will happen if someone else gets hold of your JWT token?
What happens if JWT is stolen?
The purpose of a token (session or JWT) is to help a server remember, who somebody is. JWT's can contain user data directly. Since JWTs are stateless we don't need to verify it from database or session cache. When a server-side application receives a JWT, it is validated using only the secret key (same key is used while generating the token). By doing this performance is enhanced since we are not fetching anything from database or cache.
Imagine a scenario where a valid JWT is stolen or compromised by a hacker? In that case an attacker can get full access to the user’s account. The attacker could start sending requests to the server using the stolen JWT.
The JWT will automatically expire after a set amount of time because of this attackers can only use your JWT to access the service until it expires. You can say that the stolen JWT is less harmful than a stolen username and password, because the JWT has an expiry time. However that's not true.
Suppose your username and password have been compromised. You can change it immediately, or there might be a change that the hacker would not be able to use your account if the multi-factor authentication is enabled. A compromised JWT could actually be a greater security risk than a compromised username and password.
Here's what we can do if JWT token is compromised. Though these recommendations are not suitable for every type of app.
-K Himaanshu Shuklaa..
HTTP is a stateless protocol that's why we need to send all the desired information each time, so that the server can authorize the request.
Let's say you are logged in tinder, while login you need to enter your user name and password. Tinder will verify if you are a valid user or not, if yes, it will start showing potential matches. Now if you right or left swipe on any profile, or do anything else on Tinder, it will send a request again to the Tinder server. Since HTTP is stateless, with each request you will asked to enter your credentials, which is quite irritating. To solve this problem, the session is managed.
Two of the popular ways to manage session is by using a session token or a JSON web token. After successful login, Tinder will provide some kind of token, which will be stored on client side and will be sent with subsequent requests for the authorization purpose.
Let's understand both the tokens with the help of an example.
Example of session token
Suppose a customer calls a customer support desk to raise a concern. The customer support executive creates a ticket, which will be stored in the database. He/She then provides the complaint number to the customer and tell the customer to call again tomorrow.
The customer saves the complaint no. and call again, some other customer case executive picks up the call. The customer gives the complaint number, and the executive checks the status provide updates to the user. Imagine, if we do not provide the complaint number to the customer and store the customer issues in the database, the customer has to again tell the whole story. A session token works in a similar way.
Whenever user log's in the any application, server will verify the credentials, generate the session token, store it in the database and gives the session token to the user. The user (which may be a browser or an app) stores that session token in a cookie and send it to the server with each request. The server will verify the session token before processing any request.
Problem with session token
When we are using session token, we assume there is only one monolithic server which handles each request. But in real life, there will be n number of servers, and each request will reach the server via a load balancer.
Now lets say server 1 has generated the session token, which is returned to the client. Next time when the request is received, the load balancer my send the request (with valid session token) to some different server. This server does not have the session details, hence the user request will be rejected. To resolve this we can use shared cache (e.g redis), which will have information related to each session token. All the servers will validate the token from this shared cache. The drawback is that if this shared cache goes down it will have an impact on all the servers.
To resolve this, we can make sure the load balancer to send all the subsequent requests to the server which had generated the session token. But again this is practically not possible, because when we are using micro services, its not necessary that each service is deployed on same server.
Example of JSON web token
Let's say a patient went to visit a doctor, after examining doctor prescribed some medicines and hand over the prescription along with the report to the patient.
Next time when the patient visits the doctor, he/she carry the documents. Doctor will check the previous report and prescription, before doing the examination again. If the documents are missing, the doctor will request the patient to tell the problems again. Since the patient has the previous documents, he/she doesn't need to tell the whole story again (i.e authorization is not required).
Anyone can make such (fake) documents and visit the doctor, that's why for the verification purpose, the doctor hand over the report to the patient after stamping. Next time the patient visit the doctor, before checking the report doctor will check if the report is stamped or not? If yes, then only the doctor will proceed further.
This signed document is same as JWT web token.
When you login in Tinder, the tinder server will return a JWT token (which is signed). In the subsequent request the browser or app will send this JWT token, tinder server will first check token (by verifying the signature) and then process the request.
Problem with JWT token
In case of JWT, the communication for the verification happens between a client and server only, the information related to JWT token is not stored in DB. What will happen if someone else gets hold of your JWT token?
What happens if JWT is stolen?
The purpose of a token (session or JWT) is to help a server remember, who somebody is. JWT's can contain user data directly. Since JWTs are stateless we don't need to verify it from database or session cache. When a server-side application receives a JWT, it is validated using only the secret key (same key is used while generating the token). By doing this performance is enhanced since we are not fetching anything from database or cache.
Imagine a scenario where a valid JWT is stolen or compromised by a hacker? In that case an attacker can get full access to the user’s account. The attacker could start sending requests to the server using the stolen JWT.
The JWT will automatically expire after a set amount of time because of this attackers can only use your JWT to access the service until it expires. You can say that the stolen JWT is less harmful than a stolen username and password, because the JWT has an expiry time. However that's not true.
Suppose your username and password have been compromised. You can change it immediately, or there might be a change that the hacker would not be able to use your account if the multi-factor authentication is enabled. A compromised JWT could actually be a greater security risk than a compromised username and password.
Here's what we can do if JWT token is compromised. Though these recommendations are not suitable for every type of app.
- Blacklisted JWT Token's: You can maintain list of all the blacklisted tokens and prepare a revocation list on your server to invalidate tokens.
- Request the client to change their password immediately: Attacker can use the stolen JWT to change the password, that's why the password should be changed immediately.
- Session Token is a reference token, since based on the session token details are fetched from the database and then authorization happens.
- JWT is value token since it contains all the relevant information to do authorization.
-K Himaanshu Shuklaa..
No comments:
Post a Comment