Authorisation
Different to Authentication, Authorisation is what the user allowed to do
Session based authorisation
Basic concept
For session based authorisation, we typically used a SessionId which is stored in a Http-only cookie.
The server then parse this id from the cookie, and then search in the Session database for the current user for authorisation.
The flow works as following:
Scaling
Scalability
Because the process from start to end is stateful, we need a centralised server to handle the session storage.
Token based authorisation
Basic concept
We can use JSON web token (JWT) to act as an Access Token to maintain a stateless communication between user and server.
The JWT itself will contains the information about the user and hashed inside the JWT token.
The JWT token can be stored in both
- HttpOnly cookie if the token size is < 4KB
localStorageif the token size > 4KB and < 5 MB- Some argues that Local Storage is not secure enough, but it's restricted to only the same domain so it's can be considered as secured as Cookies > SameSite
- The only downside of storing JWT in
localStorageis the attacker could read the value of the JWT token and whereas for HttpOnly Cookie it's impossible for the attacker to read the cookie. - However if the site is vulerable to CSRF (Cross site request forgery attack), there are multiple different way to exploit. Also if the client is attacked, the attacker would rather execute the script on the spot rather than obtain the token since we can implement expiration mechanism
Scaling
We don't really need to worry about scaling as the same token can be used between different server — since the user details are hashed within the token.
However we need to worry about a token expiration validation system. For example:
Note that in here we use Access Token as a way to communicate the permission of user. We can hash the permission in access_token using JWT standard.
For token expiration, we can simply read the timestamp iat in the body attribute of JWT > Signature part