Educational sandbox. Every flow, token, and scenario here is simulated. Not for production.
These labs are hands-on. Open on a desktop or tablet.
← All modules
1
Basic

Identity Foundations

One room, one guard at the door, one folder marked Salaries — Secret. Every login screen you've used is doing roughly what this guard does. Here it is, five times.

Each scene runs a real request through the real gate. Call it before you reveal it.

1

A stranger at the desk

Someone walks up and asks for the salaries folder. They haven't said who they are.

Should the guard hand it over?
2

“I'm Riya.”

Riya walks up and says she works in Finance. She's telling the truth. She hasn't shown anything to back it up.

She's told the guard who she is. Is that enough?
3

Riya proves it — then asks to delete

Riya enters her password and it checks out. She really is Riya, a regular employee. She asks to delete an old file, a public one.

She is who she says she is. Does she get to delete it?
4

A verified guest asks for salaries

Dev is a contractor here for two weeks, on a guest account. He's signed in and verified. He asks to open the salaries folder.

Verified, trusted enough to be in the building. Yes or no?
5

An ordinary yes

Riya opens a public file. Nothing unusual about it.

Last call: does she get it?

The same four questions

The guard asked the same four questions every time, in the same order, and stopped at the first one that failed.

  1. Who are you?Identification
  2. Can you prove it?Authentication
  3. Are you allowed to do this?Authorization
  4. Is it written down?Accountability

Miss one and the rest stop being worth much: a proven identity with no permission check is a stranger holding a key. You'll see these four shortened to IAAA.

One gate that every request goes through, asking the same questions in the same order, with no way around it. Security people call that a reference monitor.

The guard has no opinions

None of that was the guard's judgment. Somebody wrote the rules out beforehand; the guard reads the list top to bottom and stops at the first rule that matches. That list is the policy. It is also the only thing you change when you want a different answer.

The five scenes ran against this policy. Four rules; the rule_ names are the ones the reveals showed you.

  1. rule_no_identityDENY

    Identification: the request carries no identity, so there is no subject to reason about. This is the first gate.

  2. rule_not_authenticatedDENY

    Authentication: an identity was claimed but never proven, so it cannot be trusted with any access.

  3. rule_delete_needs_adminDENY

    Authorization — least privilege: delete is a high-impact action, so it is reserved for admins even for an authenticated user.

  4. rule_secret_needs_clearanceDENY

    Authorization — need to know: secret resources are not readable by a guest with no business reason to see them.

Anything the list doesn't object to is allowed, which is why scene 5 got through. Later modules keep this shape: more signals, longer rule lists, the same four questions underneath.

Now build your own request

The five scenes were fixed. This one is yours: change anything on the left and the gate re-decides. Try an Employee choosing Delete, or a Guest opening a Secret file, then find a combination you can't predict.

Set Riya's request on the left to see the gate's decision.