- Cookie-Based Authentication
- Web-client (eg: web-browser) stores cookie sent by the web-server after successful authentication.
- Cookie contains info about the user, client, authN timestamp and other useful data with unique-id to determine the cookie.
- Typically, cookie is encrypted by the web-server with domain attribute set (eg:
google.com) and send it across to the web-client.
- Whenever the web-client wants to access the domain resource (eg:
mail.google.com), it will send all cookie based on its domain (eg: google.com) to the web-server, which validates/ verifies and grant/ deny access based on state and timestamp of the cookie.
- Session-Based Authentication
- Along with the web-client cookie, if a web-server stores the user authN data in their back-end, then it will be called Session-based authentication.
- This is very useful in the event of any breach that the web-client gained access to the system where it shouldn’t get access, then from the back-end, the web-client’s session can be revoked by the admin.
- Token-Based Authentication (client + user based)
- Generally this is used in non web-client scenarios, where there is no way to store cookie in the client side.
- Hence, the web-server sends the signed token (contains info about user, client, authN timestamp and other useful data with unique-id) to the client after successful authentication.
- Whenever, a client wants to access a resource, it need to send this token and web-server validates/ verifies the token before it allow to access the resource.
- Claims-Based Authentication (user attribute based)
- This is same as token-based authentication + authorization data into the token about the user attributes/ roles/ groups.
- These data are pertain to authorization, which talks about what the user can do within the resource (eg: mail.read, mail.delete, admin).
Code Fluence 