Clarifying the confusion between login and permission checks through real security incidents and the 'Airport Security' analogy. Deep dive into JWT structure, OAuth 2.0, and Authentication strategies in Microservices.
A comprehensive deep dive into client-side storage. From Cookies to IndexedDB and the Cache API. We explore security best practices for JWT storage (XSS vs CSRF), performance implications of synchronous APIs, and how to build offline-first applications using Service Workers.
App crashes only in Release mode? It's likely ProGuard/R8. Learn how to debug obfuscated stack traces, use `@Keep` annotations, and analyze `usage.txt`.
Bitcoin is just part of it. How to create trust without a central authority, principles of decentralization, smart contracts, gas fees, Layer 2 solutions, DAOs, and the Oracle Problem.
Why your server isn't hacked. From 'Packet Filtering' checking ports/IPs to AWS Security Groups. Evolution of Firewalls.
Back when I was a beginner creating my first internal admin page, I proudly announced: "Hey, I finished the login feature perfectly! Now anyone can log in and see the real-time sales data."
I expected praise, but my mentor's face turned pale. "Hey! What if a summer intern logs in and sees the executive salary tables? Did you implement permission checks?"
I was confused and asked back: "If they have the right ID and password and got in (Logged in), shouldn't they be able to see everything? Isn't that the permission check?"
That day, I learned the most fundamental and critical concept in security: the difference between Authentication and Authorization, in a very harsh way. Since their spellings are similar (Auth...), 9 out of 10 developers confuse them. Today, I will clearly distinguish them for you.
My biggest confusion was thinking, "Isn't login itself granting permission?" If you unlock your house door (Login/Authentication), you can open the fridge or watch TV (Authorization) as you please. So I thought websites worked the same way—once you're in, you're free.
But a web application is less like a house and more like a "Hotel" or a "Huge Corporation". Just because you passed the lobby (Login), doesn't mean you can freely enter the CEO's office or the server room (Specific Resources).
Also, the HTTP status codes 401 Unauthorized and 403 Forbidden drove me crazy. Why give 401 for "Unauthorized" and 403 for "Forbidden"? Aren't they the same thing?
The analogies that cemented this concept in my mind forever were "Airport Security" and "Hotel Key Card".
401 Unauthorized (I don't know who you are, get out).403 Forbidden (I know who you are, but you can't come in here).Applying this analogy made everything clear. "Ah, Login is the process of getting the Key Card (Authentication), and Accessing the Admin Page is using that key to open a VIP room (Authorization)!"
The most commonly used 'Digital Passport' in modern web is JWT.
A JWT consists of three parts using . as a separator: Header.Payload.Signature
The server issues this JWT upon successful login, and the client sends this token in the header with every request. The server only needs to verify the Signature to authenticate "Ah, this is definitely user123" without querying the DB.
How do we grant permissions to an authenticated user?
The most common mistake. Thinking it's safe because you set isAdmin to false and hid the "Admin Button" in React.
Hackers don't look at the frontend UI. They poke the Backend API directly with curl or Postman.
You MUST check permissions again in the Backend API.
Logged in, but viewing someone else's data.
GET /orders/123 (My order) -> OKGET /orders/124 (Someone else's order) -> Must Block!If you only check "Is user logged in?" (Authentication) and skip "Is this user the owner of order 124?" (Authorization), you get hacked. This is a famous and dangerous vulnerability that even Facebook had in its early days.
// BAD: Checks only Authentication
app.get('/orders/:id', ensureLoggedIn, (req, res) => {
const order = db.findOrder(req.params.id);
res.json(order); // Just shows Order 124 to User 123!
});
// GOOD: Checks Authorization (Ownership) too
app.get('/orders/:id', ensureLoggedIn, (req, res) => {
const order = db.findOrder(req.params.id);
if (order.userId !== req.user.id) { // Check Ownership
return res.status(403).send("Not your order.");
}
res.json(order);
});
In MSA, Auth becomes trickier.
This avoids duplicating login logic in every microservice.
Technically, it is an Authorization framework. "I authorize this app (Client) to access my Google profile info." However, practically, it is widely used as an Authentication means (Login with Google). (OpenID Connect was added to standardize this use case).
Since JWT is stateless, the server can't "revoke" it once issued. So "True Logout" is hard.
Half of security incidents happen because these two concepts are confused.
Opening the front door (Authentication) doesn't mean you can open the safe in the bedroom (Authorization). When developing, always remember the airport staff's line: "Do you have your passport (Authentication)? Now let me check your boarding pass (Authorization)."