Design the model before the middleware.

Quick start

Begin with one resource, one subject and one successful path. Add recovery and denial cases only after the primary session lifecycle is clear.

{
  "resource": "workspace",
  "flow": ["identify", "verify", "issue_session"],
  "session": {
    "absolute_ttl": "12h",
    "idle_ttl": "45m",
    "renewal": "verified_device"
  }
}

Flows

A flow is a directed sequence of identity steps. Each step accepts evidence, records an outcome and selects the next valid transition.

Keep branches explicit

Recovery, enrolment and step-up verification should be modeled as named branches. Avoid hiding security transitions inside generic callbacks.

• Give every transition a human-readable reason.
• Separate identity proof from access authorization.
• Document cancellation and timeout outcomes.

Sessions

A session connects verified identity evidence to a bounded period of access. Model both absolute lifetime and inactivity limits, then define which changes require re-verification.

session:
  audience: workspace
  idle_timeout: 45m
  absolute_timeout: 12h
  rotate_on:
    - privilege_change
    - recovery_complete
  revoke_on:
    - device_removed

Policies

Policies answer a narrow question: may this subject perform this action on this resource under the present context? Keep authentication strength as one input, not the entire decision.

1. Resolve the subject and resource.
2. Load the named policy revision.
3. Evaluate roles, scopes and contextual constraints.
4. Record the outcome and decisive rule.

Events

Events form the explanation layer. A useful event says what changed, which model revision was used and how it relates to the surrounding session.

Do not record secret material, raw recovery codes or complete authentication assertions. Store identifiers and outcomes sufficient for review.

Standards

LoginLab uses OpenID Connect terminology for identity, OAuth terminology for delegated authorization and WebAuthn concepts for public-key credentials. Protocol details remain at the boundary of the domain model.

Review snapshots

A snapshot is an immutable view of flows, policies and session rules at a point in time. Use it as the unit for architecture review and attach decisions to that exact revision.