Authentication and access

Knowing who signed in is the beginning of an access decision. A clinic must also decide whether that person may read this appointment, modify this record, or administer the service. The same identity may be permitted one action and denied another.

Objects, actions, and relationships

Object authorization checks access to a particular record. Function authorization checks an operation or capability. The policy may depend on role, ownership, tenant, delegation, or a care relationship. Guess-resistant identifiers reduce discovery; they do not replace permission checks.

Enforce rules on the server for each relevant operation. Read-only views, batch actions, exports, and background jobs deserve the same attention as visible edit buttons.

Sessions are continuing authority

A session lets the application relate later requests to earlier authentication. Renew session identifiers on authentication and relevant privilege transitions to reduce fixation risks. Apply expiration and revocation suited to the application. Cookie attributes provide additional browser protections without deciding access to records.

Do not treat IP address or a TLS connection as a universal session identity: mobile networks change, intermediaries exist, and connections can be replaced. Context signals may support risk decisions but can also inconvenience legitimate users.

Scenario: the clinic’s external issuer

The clinic accepts JWTs from its trusted identity provider. It verifies cryptographic protection using an explicitly allowed algorithm and key policy, then checks issuer, intended audience, validity times, and token purpose. Claims may come from a trusted external issuer; the clinic need not mint every token itself.

Validated claims inform authorization, but their meaning and freshness must fit the application. When a staff role is removed, the design needs an appropriate revocation, short lifetime, or current-policy check. A database lookup on every request is one design choice, not a universal JWT requirement. RFC 8725 explains token-validation pitfalls.

Recovery is an authentication path too

Reset and recovery tokens need sufficient unpredictability, limited lifetime, appropriate single-use behavior, and protection against disclosure. Changes to authenticators or recovery addresses should follow explicit assurance and notification rules.

MFA improves the flows it covers. It does not prevent every phishing method, stolen-session use, or weakness in recovery. Online throttling and monitoring address repeated attempts; permanent lockout can itself deny legitimate access.

A useful review documents which actor, resource, action, and identity evidence the server uses, then distinguishes confirmed access failures from missing design information.

Worked review: a valid token with an outdated role

A JWT is a token format that carries claims; readable claims become trustworthy inputs only after the required validation. The fictional clinic uses signed access tokens and these owner-supplied records:

A1, policy: Clinicians may read assigned appointments only. Removing that role must prevent further appointment reads within two minutes. Dani is assigned A17, not B42.

A2, before removal: The API validates Dani’s access token for audience ClinicAppointments. It permits reading A17 and denies B42.

A3, after removal: At 12:00 the owner removes Dani’s role. The signature validates, and the token expires at 12:30. At 12:04, the API still accepts the old role claim and returns A17. The times share a clock.

A4, separate validation case: Another signed token from the same issuer is intended only for StaffPortal. ClinicAppointments is not an accepted audience for that token, and there is no token-exchange arrangement.

PredictDoes A3’s valid signature and future expiry make the 12:04 read correct?

No. Signature validity does not establish that the role still meets the application’s current authorization policy. A1’s two-minute requirement has elapsed. The supported finding is stale authority accepted for this read, not a broken signing algorithm.

Choose a lifecycle that meets the requirement

The owner and application team need an enforcement design whose delay is compatible with two minutes. A current authorization check, bounded cache, revocation mechanism, or suitably constrained token/session lifetime may contribute. A design that relies only on this token’s 12:30 expiry does not meet A1.

Each choice has tradeoffs: checking current state introduces a dependency; caching needs an explicit freshness bound and failure behavior. Removing a role only from a screen changes presentation, not the server’s decision. Document the actual path used for background jobs and exports too.

A4 should be rejected for this API despite the trusted issuer and valid signature. Audience validation answers where the token is intended to be used. A2 is different: token validation succeeds, then object policy correctly denies B42.

Acceptance should demonstrate that Dani loses appointment reads within the required interval, another authorized clinician retains assigned access, and cross-assignment reads remain denied. Record which token, session, and operation were evaluated without retaining live credential material. This verifies the specific boundary without claiming that MFA or one passing login covers every recovery and session path.