In Game of Thrones, getting inside the castle is rarely the real problem. Staying alive once you're inside is.

Authentication is getting past the gates. Authorization is everything that happens after.

And that's where most systems fail quietly.

Authentication: Getting Through the Gate

Authentication is simple.

Are you recognized? Do you have a sigil? Can you prove who you are?

In software terms:

• Credentials verified
• Token issued
• Session created

The gate opens.

Most systems relax at this point — as if the hard part is over. It isn't.

Authorization: Who Holds Power Right Now

In Westeros, identity is never enough.

Being a Stark doesn't mean you can:

• Command the Night's Watch
• Sit on the Small Council
• Issue orders across kingdoms

Power depends on:

• Role
• Context
• Timing
• Location
• Allegiance

Authorization works the same way.

The question is not who you are — it's what you're allowed to do right now.

A Jon Snow / Night's Watch Example

When Jon Snow joins the Night's Watch, his identity becomes irrelevant.

Inside the Watch:

• He doesn't get special treatment
• He doesn't inherit authority
• He doesn't bypass rules

Permissions are earned slowly and scoped carefully.

Authentication got him inside the Wall. Authorization dictated every action after.

When Rules Are Broken (Privilege Escalation)

Here's where the analogy becomes uncomfortable.

When members of the Night's Watch break rules:

• They act outside their authority
• They bypass command structure
• They take actions not permitted by their role

The result is chaos — or collapse from within.

In software, this is privilege escalation.

No gate was broken. No identity was faked. Permissions were simply assumed.

A Real-World Authorization Exploit

A user requests their own invoice:

GET /api/invoices/48392

The backend checks:

• Valid token (YES)
• Authenticated user (YES)

What it forgets to check:

• Does this invoice belong to this user?

Change the ID:

GET /api/invoices/48393

Another customer's data appears.

Authentication succeeded. Authorization failed silently.

Why This Happens So Often

Systems rely on assumptions:

The frontend won't allow that

Only trusted users know this endpoint

They're already logged in

Attackers don't break systems. They explore assumptions.

Why Roles Eventually Stop Working

Roles feel safe: Admin, User, Viewer.

Just like: Lord, Commander, King

But titles don't grant unlimited power.

Even the King couldn't command the Night's Watch at will.

This is where scattered if checks pile up — and clarity disappears.

Multi-Tenant Systems: Different Kingdoms, Same Gate

In SaaS systems, tenants are kingdoms.

Authentication gets you into a kingdom. Authorization decides which one.

A request like:

GET /api/tenants/42/users

If the system checks only: Is the user authenticated?

But not: Does the user belong to tenant 42?

Then one banner can move freely across kingdoms.

Why Tests Rarely Catch This

Most tests ask:

Can the right user do the right thing?

Attackers ask:

Can the wrong user do the wrong thing?

Authorization failures don't crash systems. They don't throw errors. They look normal.

Until they aren't.

Authentication opens the gate.

Authorization decides:

• Which rooms you enter
• Which orders you give
• Who pays the price when rules are ignored

In Game of Thrones, most characters died after they were inside the castle.

In software, most breaches occur similarly.

That's why authorization feels harder.

Because power, context, and trust always are.