Softlander Book a call
Security software engineering

Identity, authentication, authorisation and secure-session engineering

Decide how identity is proved, carried and revoked across the product's components

A federation, a token model or a session lifetime is being designed, or an authorisation bug has exposed an assumption. The decision is how identity is proved, carried and revoked across the product's components. The work starts from how an identity assertion is produced, validated, propagated, narrowed and revoked across every hop and ends with an identity and session design review with propagation, scope and revocation findings. It is most relevant to platform engineers and identity owners. A useful result states what was examined, what remains uncertain and which decision the evidence can support.

Book a 30 minute readiness callBrowse this capability group

Decide how identity is proved, carried and revoked across the product's components

  1. Starting pointIdentity assertion

    The starting condition this work depends on.

  2. ExaminationAuthority narrowing

    Where the consequence actually arises.

  3. DecisionRevocation path

    The finding and its open dependencies.

Proposed working model, not exhaustive coverage.

Decision

Frame the decision before scoping the work

Questions and the evidence each one needs

Question / evidenceIdentity assertion
Inspect the identity provider configuration and token formats.
Question / evidenceAuthority narrowing
Inspect the authorisation model and where it is enforced.
Question / evidenceRevocation path
Inspect session lifetime, refresh and revocation behaviour.
Read each question against evidence already available.

The decision is how identity is proved, carried and revoked across the product’s components. This matters to platform engineers and identity owners when a federation, a token model or a session lifetime is being designed, or an authorisation bug has exposed an assumption. Name the affected product, the consequence of a wrong decision and the owner who can act. The opening conversation should establish which evidence already exists and which uncertainty is material enough to investigate.

The specific failure hypothesis is that a token is validated at the edge and then forwarded internally as a trusted assertion nobody re-checks. It stays a hypothesis until it is examined in your own case. Existing design records, tests or operating evidence may already resolve it, so identify the uncovered question before commissioning further work.

Mechanism

Follow the relationship that carries the consequence

Where the boundary is actually crossed

SourceIdentity assertion
The condition the design assumes.
CrossingAuthority narrowing
Where authority or information changes hands.
ConsequenceRevocation path
The effect the owner must answer for.
Evidence comes from the configuration that will ship.

What this specialty examines

Identity, authentication, authorisation and secure-session engineering rests on how an identity assertion is produced, validated, propagated, narrowed and revoked across every hop. Work from the configuration that will actually ship rather than from the reference design, and record where the two differ.

The examination draws on the identity provider configuration and token formats; the authorisation model and where it is enforced; and session lifetime, refresh and revocation behaviour. Identify the owner, revision and operating context of each source. Keep an incomplete input visible, with an explanation of what its absence prevents the owner from concluding, rather than quietly treating a gap as a satisfactory result.

The tradeoff to make explicit

The tradeoff here is long-lived sessions that users prefer against revocation that takes effect promptly. Compare the available options against the same intended outcome. If one option removes a control or moves a boundary, describe that difference before treating its lower effort as an improvement. The decision should expose the tradeoff rather than bury it in a single rating.

Preparation

Connect the inputs to the boundary examined

Preparation record for the engagement

Illustrative working format

BasisThe identity provider configuration and token formats
Bounds the context.
MaterialThe authorisation model and where it is enforced
Supplies the material examined.
ConditionSession lifetime, refresh and revocation behaviour
Exposes conditions that qualify a result.
Illustrative record; availability and handling need confirmation.

Start with the identity provider configuration and token formats; the authorisation model and where it is enforced; and session lifetime, refresh and revocation behaviour. Each has a different job: the first establishes context, the second supplies the material to examine, and the third exposes operating conditions that may qualify a conclusion. Sanitised examples can support early work, provided the differences from the real configuration stay explicit.

The scope also needs platform engineers and identity owners with the authority to inspect the relevant boundary, and agreement on what evidence would distinguish the failure in which a token is validated at the edge and then forwarded internally as a trusted assertion nobody re-checks from acceptable behaviour. Where stakeholders disagree about intended behaviour, resolve that interpretation before classifying an observed difference as a defect.

Working sequence

Carry the question through to an accountable finding

From scoped material to a decision record

  1. EstablishMap the identity path

    Set the conditions assumed.

  2. ExamineExamine authority and scope

    Apply the scoped check.

  3. RetainDesign lifetime and revocation

    Record evidence and the next decision.

Proposed sequence; resolve access gaps first.

Map the identity path

Follow a human and a workload identity from authentication through each service hop to the resource, recording who validates what at each step. Record what is deliberately excluded.

Examine authority and scope

Check whether authority narrows as it propagates, whether audience and scope are enforced, and whether any hop can act beyond the original grant. Keep an unreproducible observation in the record with its reason.

Design lifetime and revocation

Agree session and token lifetimes, refresh behaviour, and the revocation path that must work during an incident. Hand the result over with its open dependencies attached.

Indicative artefact

Make the artefact usable by the person who owns the decision

An identity and session design review with propagation, scope and revocation findings

Illustrative working format

Annotated fieldThe mapped identity and authority path
What was examined, and under which assumptions.
Annotated fieldScope, audience and propagation findings
Each observation, linked to evidence.
Annotated fieldLifetime and revocation decisions
The next decision, and its limits.
Illustrative structure, not a completed engagement.

The proposed decision artefact is an identity and session design review with propagation, scope and revocation findings. Depending on the agreed scope, the pack may include:

  • The mapped identity and authority path. Basis: the definitions, boundaries and assumptions another reviewer would need.

  • Scope, audience and propagation findings. Observation: the findings and their interpretation, preserving adverse results and disagreement.

  • Lifetime and revocation decisions. Decision: what the owner could do next, and what change would justify revisiting it.

Retain the selection rationale beside the result. Without it, a bounded finding is easily mistaken for complete coverage.

Illustrative scenario

Examine the question through a constructed case

A constructed case and its decision paths

Illustrative scenario

  1. SituationIdentity assertion

    A long-lived refresh token remains valid after an account is disabled because revocation only reaches the login service.

  2. Question to examineAuthority narrowing

    Which component would observe the revocation, and within what time?

  3. Conditional next actionRevocation path

    Define the revocation path each token-consuming service honours, and the delay the business will accept.

Fictional example; no engagement or outcome is implied.

Consider an illustrative situation: a long-lived refresh token remains valid after an account is disabled because revocation only reaches the login service. The example is constructed to show how the question is framed. No client engagement, executed test or measured improvement is implied.

The question to examine is which component would observe the revocation, and within what time. A reasonable next action would be to define the revocation path each token-consuming service honours, and the delay the business will accept. The decision record should state which configuration was accepted and which limitations came with it.

Scope and next action

Keep the conclusion inside the agreed boundary

Confirm fit before the next commitment

Included boundaryIdentity assertion
Limited to the agreed scope and configuration.
PrerequisiteThe identity provider configuration and token formats
The owner confirms access and conditions.
Claim limitRevocation path
The review covers the identity flows examined. It does not assess the identity provider's own implementation or its operational security.
Bring the triggering change and the evidence you hold.

The review covers the identity flows examined. It does not assess the identity provider’s own implementation or its operational security. Any engagement depends on an agreed scope, a qualified team and authorised access.

Bring the affected product or workflow, its current configuration and the evidence you already hold. The scope question follows from the situation in which a federation, a token model or a session lifetime is being designed, or an authorisation bug has exposed an assumption. Confirm which missing observation would change the owner’s next action.

A little more clarity

Questions to consider.

Start with the questions that shape a better decision.

When is identity, authentication, authorisation and secure-session engineering the right work?

It suits platform engineers and identity owners when a federation, a token model or a session lifetime is being designed, or an authorisation bug has exposed an assumption. Stated plainly, the decision it supports is how identity is proved, carried and revoked across the product's components. If none of that applies yet, a shorter framing conversation is more useful than a scoped engagement.

What would our team need to provide?

Start with the identity provider configuration and token formats; the authorisation model and where it is enforced; session lifetime, refresh and revocation behaviour; and service-to-service authentication arrangements. Identify the owner, revision and operating context of each. A missing input should be recorded as an evidence gap rather than assumed to be satisfactory.

How is the scope bounded?

The work examines how an identity assertion is produced, validated, propagated, narrowed and revoked across every hop within an agreed boundary. The review covers the identity flows examined. It does not assess the identity provider's own implementation or its operational security. State the boundary in writing before the work starts, so a later reader can distinguish what was excluded from what was missed.

What does the engagement produce?

The proposed artefact is an identity and session design review with propagation, scope and revocation findings. It carries the mapped identity and authority path; scope, audience and propagation findings; and lifetime and revocation decisions, with the open dependencies still attached so the owner can see what the evidence does not cover.

What if our existing evidence already answers this?

Review its scope, provenance and configuration first. Work already done by platform engineers and identity owners may be sufficient. Record the decision, the unresolved limitations and the change that would require another look. Further work should address a real gap.

What tradeoff should we expect to decide?

The recurring tradeoff is long-lived sessions that users prefer against revocation that takes effect promptly. Neither side is universally correct. The engagement makes the difference explicit and leaves the choice with the owner who carries its consequence.

What would make the findings inconclusive?

Missing the identity provider configuration and token formats; the authorisation model and where it is enforced; and session lifetime, refresh and revocation behaviour can prevent a reliable interpretation. Record the specific missing observation and its implication. The owner can supply the evidence, narrow the claim or defer the dependent decision; an incomplete case should not silently count as a pass.

Start with the decision you need to make.

Tell us about the agent workflow you want reviewed, and where you need greater clarity. Scope and availability are confirmed together.

Book a 30 minute readiness call Get the agent release checklist

Connected disciplines

Secure software architecture and threat modelling

Agree which trust boundaries and attack paths the architecture must defend. The work examines how data, credentials and privileged operations cross each boundary in the intended deployment, for software architects and product security leads, and produces a threat model with ranked attack paths and the architectural mitigations attached to them.

Secure development lifecycle and DevSecOps

Decide which security activities belong in the delivery pipeline and which need human judgement. The work examines where a security activity changes a decision, and where it only produces an unread artefact, for engineering leaders and platform teams, and produces a secure development lifecycle design with placed controls, ownership and exception handling.

Security testing and release assurance

Decide what security evidence a specific release requires before it ships. The work examines whether the available evidence covers the code and configuration actually being released, for release owners and security assurance leads, and produces a release security evidence pack with coverage, residual findings and named dispositions.