Authentication
First focus on "WHAT".
Authentication is the act of proving an assertion, such as the identity of a computer system user. In contrast with identification, the act of indicating a person or thing's identity, authentication is the process of verifying that identity. It might involve validating personal identity documents, verifying the authenticity of a website with a digital certificate, determining the age of an artifact by carbon dating, or ensuring that a product or document is not counterfeit.
OKAY.🤨! But it is kinda hard for me. Let's understand with a simple example. For example, you're Sheldon Cooper you go to the bank to withdraw money. You say to the cashier give me $5000, they were like "Who are you?? I don't know you so I can't". This happens because they don't know you, to identify you as a real holder of your bank account. They provided you a bank account number and pin/signature to identify you. When you give these details to the cashier, he will like "Thank you! Mr. Cooper, here is your $5000". So this shows that by giving the details it identifies you as the real holder of the bank account. So the process or action of verifying the identity of a user or process is Authentication.
Types of Authentication
- Stateful
- Cookie/Session Based Auth.
- Stateless
- Basic Auth
- JWT
- OpenID Connect
Stateful Authentication
Stateful Authentication is a way to verify users by having the server or backend store much of the session information, such as user properties.
In this method whenever a client requests to the server, the request carries the unique-id provided by the server at the authentication time and this ID is matched against its identity provider (IdP).
Stateful authentication is also called session-based authentication or cookie-based authentication for the session information the server must store on the user.
Advantages
- Revoke the session anytime.
- Easy to implement and manage.
Disadvantages
- Increasing server overhead: As the number of logged-in users increases, the more server resources are occupied.
- Server has to store the session id which limits scalability.
Stateless Authentication
Stateless authentication is a way to verify a user by storing its data on the client-side and signing it with some cryptographic signature. This signed data is known as a token. Whenever a client tries to request the server, the server verifies the signed token, check if the token is valid or not.
Advantages
- Easy to scale
- Lower server overhead: Server does not have to allocate resources to the client.
Disadvantages
- Cannot revoke the session anytime: As token is stored at client side, server does not have any rights to delete the session.
- Relatively complex to implement: It increases the technical complexity while implementing.
- If a token gets steal before expiring and a hacker uses it, the server has no way to identify it. That's why token's expiry time should be less(<=15min).
| Stateful | Stateless | |
|---|---|---|
| Session information could be stolen | ✅ It is impossible to steal session information from the session identifier because it is just an identifier associated with the session | ❌ Session identifier contains all authentication information and it is possible to steal sensitive information, it is not encrypted. |
| Resource consuming | ✅ When retrieving session information, service always gets access to session storage which causes additional resource consumption. | ❌ The session identifier contains all session information. |
| Easy to implement | ✅When session information stored in an external database, there is a need to implement session database persistence | ❌Session identifier contains all session information, there is no need to implement additional functionality |
| Easy to scale | ❌While adding new instances, there is a need to implement additional scale to session storage as well | ✅Adding new service instances does not require additional effort |
| Authentication token size | 🤏It is just an identifier, So size is small | 🥵 It contains a large amount of data, the authentication token also becomes large |
| Restrict access among different parts of an application | ✅It is possible to configure the system so different parts of the system will only have access to the data necessary for their work | ❌All parts of the system have access to all session data |
| Possibility to revoke session | ✅It is possible to revoke a session at any time | ❌Since the session token contains an expiration date, it is impossible to revoke the authentication session |
Conclusion
Both approaches make sense, both have their advantages and disadvantages. Stateless authentication easier to implement and scale, but stateful authentication is more secure and easier to manage. In the next part, we'll understand each way of authentication like JWT, Cookie, OAuth, Etc. 👋🏻
Top comments (16)
Unfortunately authentication is a word often misused.
Authentication is about confirming that you are you say you are and authorization is about knowing what you can do.
Because we use different means to implement and optimize this, we usually end up using tokens or cookies. They get validated to then allow the authorization to happen. But they are not part of the authentication flow.
But I can understand why they are collapsed together because the tools give you that perception.
How it helps you understand better the flow at least on the theoretical level.
Yes, you are right Authentication and Authorization can sometimes be confusing. That's why I'm writing this series to explain What, and various part of Authentication.
If we want to understand Authentication and Authorization in simple terms, Authentication is validating/identifying that is the user is correct or not and Authorization is giving users rights/privileges to use resources.
For example, You go to the cinema hall to watch a movie, while entering guard check your ticket and authenticate that you pay for the ticket or not. Ok, now while roaming around you see VIP lounge but you are not authorized to go there. But if you are a good friend of the owner and he Authorize you to go to the VIP room then that is authorization.
That's why I tried to expand.
In real life it is not always to map this for various reasons.
But let's say you have an identity card and you give to a clerk in the town hall. Only card(token) validation happens. It is actually much more complicated because you are in context of federation. But I don't want to confuse you. In any case, authentication happened once when the card was issued. I'm referring to countries where the card is electronic.
Yes, you explained it very well. Only the initial step is authentication after that everything is authorization till the ID gets expires. Session-ID stored in Cookie or JWT Token is just an authorization ID provided by the server which allows us to perform various functions on server resources. But on the initial steps, I have categorized stateful, stateless and everything else.
I'm not convinced this is a fair assessment of the two.
The stateful / stateless description makes sense, but why mention JWT, OpenID and so on in the intro if you're not going to explain what that is ?
Zero to Hero is a series of posts. If you're intrested in sub-classification you can read Part 2. In part 3 I'm going to implement JWT
Excellently written - thanks for explaining it in simple words! 👏
😁
Nice one. I did a research on something related to this last year . good work
Thank you 😁
Useful post, but in the comparison section between stateful and stateless Authentication I saw that you've used the wrong icon with the reference page, easily confused for reader.
Thanks, I'll correct it. 😅
Great work thanks!
Thanks☺
Great Work 😁