Identity proof and resource decisions

A successful credential check should produce a principal with validated authority and relevant claims, not merely a Boolean that any internal caller is trusted. The application still needs to decide whether that principal may read, update, delete, or delegate access to the requested resource. A network location or service certificate can be useful policy context, but neither automatically establishes ownership of every object identifier present in the request.

A user-supplied tenant or resource parameter must be checked against authoritative relationships rather than copied into the authorization context as truth. An authenticated user can change a URL identifier just as an anonymous one can. Evaluate the final resource actually accessed, including redirects, aliases, and backend lookups where they affect the decision. Authorization performed on one object while the operation mutates another is a correctness failure even when the initial identity was fully valid.

When a frontend calls a backend, distinguish an authenticated service assertion from arbitrary forwarded headers. A header naming a user is trustworthy only if the backend authenticates its source and the protocol prevents callers from forging that context. Delegation may preserve both actor and subject, or the backend may rely on a carefully defined service authorization. Document which model applies rather than accepting every internal header as proof of user authority.

Authorization decisions can become stale when membership, ownership, or policy changes. Cache them only with keys and lifetimes covering the principal, action, resource, relevant policy version, and required revocation behavior. Reusing a cached allow for a different tenant or action can bypass a correct policy engine. Likewise, checking permission and then acting after the resource changes can create a time-of-check/time-of-use race; strict invariants may need a transaction or version condition at the resource boundary.

Test valid credentials with forbidden actions and resources, not just invalid credentials. Include same-identifier objects across tenants, recently removed group membership, and a resource whose ownership changes during a request. Audit both authentication failure and authorization denial with distinct reasons and safe identifiers. A spike in denials may reveal an overbroad client or a stale policy cache; a drop to zero denials can indicate a broken enforcement path rather than improved security.

The probability lab is a statistical contrast. Reset and set both p=0.5, n=10, predict five successes on average, then inspect. The trials are independent and interchangeable; real authentication and authorization outcomes need not be. The instrument does not validate identities, query ownership, or enforce policy. Use it to explain why multiplying two imagined success percentages is unjustified unless conditional relationships are known, then classify actual request outcomes by their distinct validation stages.