RobotnixAcademy

Week 11 · lesson

Sessions Carry Authority After Login

Most applications do not ask a user to authenticate from scratch before every request.

They establish some form of session state or token representing authenticated context for a period of time.

That convenience creates a new system boundary.

A session is not the same thing as the person

A session may carry claims such as:

account=alice
role=viewer
issued_at=12:01
expires_at=12:31
session_id=rnx-session-104

The application uses that state to make later decisions.

If session state is copied, stolen, reused incorrectly, fails to expire, or retains stale privilege, authentication at the beginning of the session may no longer protect the later action the way the designer expected.

We do not need instructions for stealing tokens to understand the defensive architecture.

We need to ask what authority the token/session carries and how its lifecycle ends.

Session lifecycle

A useful model:

AUTHENTICATE
    ↓
ISSUE SESSION
    ↓
USE FOR REQUESTS
    ↓
REFRESH / REAUTH IF POLICY REQUIRES
    ↓
EXPIRE OR REVOKE
    ↓
REJECT FURTHER USE

Each transition should have observable evidence in a well-designed system.

Expiration limits duration

A session that never expires keeps authority available indefinitely.

Expiration does not solve every session risk, but it limits one dimension: time.

Different actions may require different policies. A low-risk read-only classroom page and a high-privilege admin function do not necessarily need identical session lifetimes.

Revocation handles changed conditions

Suppose Bob's operator role is removed at 13:00.

But Bob has an active session issued at 12:55 carrying role=operator until 17:00.

What should happen?

Possible architectures include:

  • session checked against current authorization data on each sensitive request;
  • privileged sessions revoked when role changes;
  • short-lived session claims that refresh frequently;
  • explicit reauthentication for sensitive actions.

Each design has tradeoffs.

The important question is:

How quickly does changed authority become effective across active sessions?

Supplied stale-session incident

Role record at 13:00:

bob → viewer

Active session:

session=rnx-220
account=bob
role=operator
expires=17:00

Action at 13:05:

update_match_note → allowed

This reveals a consistency problem between current role state and session-carried authority in the fictional design.

Do not call it “session hijacking.” No evidence suggests another person used the session.

Controlled design correction

Choose one classroom design:

Option A: authorization lookup on sensitive actions

The session identifies Bob, but the service checks Bob's current role before each privileged update.

Option B: revoke privileged sessions on role change

Role change triggers invalidation of sessions carrying the old privilege.

Option C: very short-lived privileged claims

Limits stale authority but may increase operational complexity.

Defend one choice for the fictional system.

Secrets should not appear in classroom evidence

Do not place real cookies, API tokens, session identifiers from production services, or passwords in screenshots or assignments.

Use synthetic placeholders:

session_id=TRAINING-SESSION-220
secret_material=[REDACTED]

The purpose is to study lifecycle and authority, not collect credentials.

Lab: test session invalidation behavior

Use a paper/simulated sequence:

  1. Bob authenticates as operator.
  2. operator action succeeds.
  3. admin changes Bob to viewer.
  4. old session attempts operator action.
  5. expected result: deny under your chosen architecture.
  6. Bob reads public/allowed status if viewer role allows it.
  7. log records role change + denied stale privileged action.

Record the exact evidence your design would need.

Extend your Identity and Authorization Evidence Map

Add:

Session issuance condition:
Authority carried:
Expiration:
Revocation condition:
Role-change behavior:
Sensitive-action recheck:
Session event evidence:
Secret data excluded from artifact:

Lesson 3 turns this into a complete privilege lifecycle.