Understanding Authentication and Authorization with a Marvel Twist!

Authentication is like having Thor's ID card at the entrance to the Avengers headquarters. Imagine Thor wants to enter the headquarters, and Tony Stark (the gatekeeper) asks, "Who are you?" If Thor shows his valid Avengers ID card, Tony lets him in. In the digital world, this ID card could be your username and password.

Now, once Thor is inside the headquarters, he can't just stroll into Tony’s lab and start tinkering with Iron Man suits. Only those with the proper clearance can enter. This is where authorization comes in. It's about checking if you have permission to access specific areas or resources. So, authentication gets Thor into the headquarters, but authorization decides if he can enter Tony’s lab.

RBAC stands for Role-Based Access Control. It’s like the rules the Avengers have for who can use which gadgets. If you’re Tony Stark, you can access the high-tech lab. If you’re Hawkeye, maybe stick to the archery range. It simplifies managing who has access to what based on their role.

Imagine Thor wants to enter the headquarters. Tony won’t just take his word for it when he says, "I’m Thor, the God of Thunder." He needs to show his Avengers ID card. Similarly, when logging into a website, you can’t just say, "I’m Adarsh, here’s my email." You need to prove it with a password or an OTP (One-Time Password).

But what if Ultron hacks into the Avengers database and can see all the ID cards and passwords? That’s a big problem!

Share

We don’t store the actual password. Instead, we hash it. But, here’s a catch: the same password always produces the same hash. If Ultron gets the hashes, he can compare them with common passwords.

Enter bcrypt, the superhero of password encoding! Bcrypt hashes the same password differently every time by adding a unique "salt" to each password before hashing it. You can see this in action at bcrypt-generator.com.

HTTP requests are stateless, meaning they don’t remember anything between different requests. So, we need to send all necessary information with each request. Should we verify the user’s ID and password against the database each time? That would slow things down.

Instead, we use tokens. Think of a token like the wristband you get at an Avengers party. Once you have it, you can move freely without showing your ID every time. The database generates a token, which your browser stores. This token might also include an expiry time, and for extra security, it might be tied to your IP address or device ID.

Tokens can still require database queries to verify. Enter JWT (JSON Web Tokens), which we’ll discuss in future posts. They make token verification smoother without always hitting the database.

Share