Identity & Access Management

These two words get swapped constantly, and the confusion is expensive. Authentication (authN) answers "are you who you claim to be?" Authorization (authZ) answers "okay, but are you allowed to do this?" Authentication always comes first; authorization is every decision after.

Think of an airport. Your passport authenticates you — it proves identity. Your boarding pass authorizes you — it says which flight, which seat, which lounge. A valid passport does not get you into the cockpit. Systems encode exactly this split in HTTP: a 401 Unauthorized actually means "you failed authentication," while a 403 Forbidden means "we know who you are, and the answer is still no."

Authentication is usually built from factors: something you know (password), something you have (a phone or hardware key), and something you are (biometrics). Combining factors gives you multi-factor authentication (MFA), which defeats the vast majority of credential-stuffing and password-reuse attacks. But MFA only strengthens the first question. Once you're through the door, authorization decides everything you can touch — and a huge share of breaches are not broken logins but over-broad permissions granted to accounts that authenticated perfectly.

Single Sign-On (SSO) lets one login unlock many applications. Federation is the trust plumbing underneath: an identity provider (IdP) vouches for you, and a service provider (SP) — the app — accepts that vouching instead of managing its own passwords. Fewer passwords, one place to enforce MFA, one place to revoke access when someone leaves. Three protocols dominate, and knowing which is for what is a load-bearing skill.

The classic mistake: using raw OAuth 2.0 as a login system. OAuth was designed to authorize an app to reach an API — not to prove who logged in. Bolting authentication onto it by hand led to real vulnerabilities, which is precisely why OpenID Connect was standardized on top of it: OIDC adds a signed id_token that actually asserts identity. SAML does the same job for enterprise browser SSO, just with XML instead of JSON.

Once you know who someone is, you decide what they can do. The two workhorse models are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).

RBAC groups permissions into roles — billing-admin, read-only-analyst, on-call-engineer — and assigns people to roles. It's simple to audit and easy to reason about, which is why most organizations start here. Its failure mode is role explosion: as edge cases pile up ("analysts in the EU, but only during business hours, and not for payroll data"), you end up minting thousands of near-duplicate roles nobody can untangle.

ABAC makes decisions from attributes evaluated at request time: attributes of the user (department, clearance), the resource (classification, owner), the action (read vs. delete), and the environment (time, location, device posture). A policy might read: "permit if user.dept == resource.owner_dept and device.is_managed and time is within business hours." This is far more expressive and dynamic — the foundation of fine-grained and Zero Trust authorization — but policies grow complex and can be hard to test exhaustively.

In practice, mature shops blend them: RBAC for coarse strokes, ABAC policies layered on for context. Both should be governed by the principle of least privilege — grant the minimum access needed, for the minimum time.

Not all accounts are equal. The root, domain-admin, and service accounts that can reconfigure infrastructure or read every mailbox are the crown jewels — and attackers hunt them relentlessly, because owning one is often game over. Privileged Access Management (PAM) is the discipline of locking those down.

The core moves:

• Vaulting — privileged credentials live in a secrets vault, not on laptops or in scripts, and are checked out on demand.
• Rotation — passwords and keys rotate automatically, so a stolen credential has a short shelf life.
• Just-in-time (JIT) access — admin rights are granted for a window and then revoked, eliminating standing privilege that sits idle waiting to be abused.
• Session recording & isolation — privileged sessions are proxied, logged, and often video-recorded for forensics.
• Break-glass — a tightly monitored emergency account for when everything else is down.

For decades, security had a shape: a hard network edge with a soft interior. Get past the firewall and you were "inside," implicitly trusted. Cloud, SaaS, and remote work vaporized that model. Your data lives in a dozen providers; your workforce logs in from cafés and kitchens. There is no inside.

So the perimeter moved to identity. Zero Trust formalizes this: never trust, always verify. Network location grants nothing; every request is authenticated and authorized on its own merits, evaluated against identity, device health, and context. Identity becomes the control plane — the place where policy is enforced and where attackers now concentrate their fire.

And humans are no longer the main population. Machine (non-human) identities — service accounts, API keys, OAuth tokens, workload identities, CI/CD runners, and now autonomous AI agents — vastly outnumber human users in a modern environment, often by an order of magnitude or more. They authenticate constantly, hold real privilege, and frequently have no MFA and no owner. Secrets sprawl across code, config, and container images. The next decade of identity security is largely about governing this machine population: giving every workload a short-lived, verifiable identity instead of a long-lived secret nobody rotates.