The Foundation of Security
Think of a hospital. Before anyone can walk into the operating room, two things must happen: they must show their staff badge (proving who they are), and a guard must check whether their badge grants access to that specific room (deciding what they're allowed to do). Every secure system works the same way.
Identity is broken down into two fundamental concepts that are often confused but crucial to distinguish:
-
Authentication (AuthN): Who are you?
This is the process of verifying identity. It's proving that a user (like "Alice") or a service (like "payment-api") is genuinely who they claim to be. Think of it as showing your passport at border control — the officer checks that the document is real and that your face matches the photo. -
Authorization (AuthZ): What are you allowed to do?
Once we know who you are, what permissions do you have? Can Alice read the production database? Can the payment API write to the ledger? Think of this as the specific visa stamp in your passport that lets you work in a country, rather than just visit as a tourist.
In modern cloud architectures, we rarely manage usernames and passwords directly in every single application or database. Instead, we rely on centralized identity providers (IdPs) and standard protocols to handle AuthN and AuthZ. This separation of concerns means your application doesn't need to know how to verify a password — it delegates that responsibility to a trusted authority and simply acts on the result.
A critical architectural principle: never conflate authentication and authorization. A system that knows who you are still needs a separate, explicit decision about what you can do. Mixing these two concerns is a common source of security vulnerabilities — for example, trusting that "if the user is authenticated, they can access everything."