Following Identity Through a System: From Login to Every Privileged Action

Login is the beginning of an identity chain, not the complete security decision.

Following identity means tracing how verified credentials become sessions, service calls, authorization decisions, audit events, expiry, and revocation across every trust boundary.

Authority can be lost, broadened, or confused as requests move through systems.

A concrete example: API calls another service

A user logs in and requests an account report.

The frontend calls an API with the user's session. The API calls a reporting service using its own workload credential while preserving:

• user identity,
• tenant,
• requested scope,
• and authorization context.

The reporting service checks both the calling service and the user's right to the account.

Principal

A principal is an entity that can be authenticated:

• person,
• service,
• device,
• job,
• or organization.

Do not use one shared principal for unrelated actors when accountability matters.

Credential

A credential proves control or supports an identity claim:

• passkey,
• password,
• certificate,
• hardware key,
• API credential,
• or signed assertion.

Protect its issuance, storage, rotation, recovery, and revocation. Credentials should have the narrowest practical scope.

Authentication

Authentication verifies the current actor under a defined assurance level.

Record:

• method,
• time,
• identity provider,
• factors,
• risk signals,
• and relevant device state.

High-consequence actions may require recent or stronger authentication.

Session

A session lets the user continue without authenticating every request.

Sessions need:

• unpredictable identifiers,
• secure cookies or storage,
• expiration,
• rotation,
• logout,
• revocation,
• and protection from theft.

Do not place sensitive session tokens in URLs or broad logs.

Tokens

A token carries signed claims such as:

• issuer,
• subject,
• audience,
• expiry,
• scope,
• tenant,
• and authentication context.

The receiver must validate signature, issuer, audience, time, and required claims. Parsing a token is not validation.

Authorization

Authorization evaluates whether the principal may perform the action on the resource now.

Inputs can include:

• role,
• ownership,
• relationship,
• tenant,
• consent,
• resource state,
• risk,
• and policy.

Check server-side at every protected operation.

Tenant boundaries

Multi-tenant systems must bind identity and resource to the same tenant.

Never trust a tenant ID supplied only by the client. Derive allowed tenants from authenticated identity and verify every query, cache key, job, file path, and event.

Cross-tenant administration needs explicit separate authority and logging.

Frontend to backend

The frontend can guide user experience but cannot enforce authorization because users control client requests.

The backend should derive the principal from a validated session and ignore client claims such as isAdmin: true.

Return only fields the caller is authorized to receive.

Service identity

Services authenticate to each other with workload identity, certificates, or short-lived tokens.

Avoid static shared keys. Bind identity to deployment, environment, and service and rotate automatically.

Service authentication answers which workload called, not which user initiated the work.

Delegating user context

A downstream service may need to act for a user.

Use delegated tokens or explicit context with:

• user,
• permitted scope,
• audience,
• expiry,
• and initiating service.

Do not pass the user's broad original token to every service.

On-behalf-of versus service authority

Distinguish:

• action on behalf of a user,
• background action owned by a service,
• and administrator action.

The authorization and audit meaning differ. A nightly invoice job should not pretend to be a customer, while a report export should preserve which customer requested it.

Queues and background jobs

Asynchronous work occurs after the original request.

Store enough authorization context to validate execution, but avoid long-lived bearer tokens in queues. Use a job identity, resource reference, purpose, tenant, and policy recheck.

Decide what happens if the user's access is revoked before the job runs.

Impersonation and support

Support staff may need to view or act within a user's context.

Use explicit impersonation with:

• strong authentication,
• reason,
• approval where needed,
• visible banner,
• limited duration,
• restricted actions,
• and audit.

Never ask users to share passwords.

Delegation

A user may authorize another person or agent for a limited purpose.

Represent delegation as a separate grant with scope, duration, resource, and revocation. Do not merge identities or copy the principal's full permissions.

Show both actor and principal in logs.

Step-up authentication

Require stronger or recent proof for:

• payment,
• credential change,
• sensitive export,
• new device,
• or privilege escalation.

Bind approval to the exact action so confirmation cannot be replayed for another recipient or amount.

Expiry and revocation

Short-lived credentials limit exposure but require refresh.

Revocation may need:

• session store,
• token denylist,
• version counter,
• identity-provider event,
• or policy recheck.

Test how quickly a terminated account loses access across caches and downstream services.

Audit

Record:

• actor,
• principal represented,
• action,
• resource,
• tenant,
• decision,
• policy,
• authentication context,
• time,
• and request correlation.

Protect logs and avoid storing secrets. Audit should explain who did what under which authority.

Failure questions

At every boundary ask:

• Who is the principal now?
• How was it authenticated?
• Which audience accepts this credential?
• Which scope remains?
• Is tenant preserved?
• Can authority be widened?
• How is it revoked?
• What is logged?

Identity context should become no more powerful as it travels.

Knowledge check

1. Why is login only the start of an identity chain?
2. Which token fields must a receiver validate?
3. How do service identity and user context differ?
4. What should happen to queued work after access revocation?
5. Which identities should an impersonation audit record?

The one idea to remember

Trace identity through every session, token, service, queue, and privileged action. Each boundary must authenticate the caller, preserve the correct user and tenant context, narrow authority, recheck policy, expire and revoke access, and record who acted for whom.