A person can be correctly signed in and still be forbidden to read a particular quote. Authentication answers who the application recognizes. Authorization answers what that person may do to a particular resource.
Confusing those questions is especially dangerous in applications that serve several dealers, organizations, or customers.
Begin with the resource
Write a permission matrix using actual operations: read a design, change a catalog, accept a quote, export customer data, invite a colleague.
For each operation, identify the actor, organization relationship, resource state, and conditions that matter. A broad “admin” label may be insufficient when administrators belong to different tenants.
Use the OWASP authorization guidance as a foundation: least privilege, explicit permission checks, and denial when access has not been granted.
Resolve context from trusted information
A tenant identifier supplied by the browser is an input to verify, not proof of membership. The same applies to resource ownership and role fields.
Ensure background jobs, exports, WebSocket messages, and signed download links respect the same boundary as ordinary HTTP routes.
Database row policies can provide another layer, but they need correct session context and deployment-specific tests. They do not excuse an application from understanding its own authorization model.
Treat sessions as revocable authority
Use established authentication libraries and current provider guidance for the chosen flow. Review cookie attributes, expiration, logout, session rotation, and account recovery.
A signed token is not necessarily confidential, and a valid signature does not settle whether its claims are appropriate for this operation. Validate the intended issuer, audience, lifetime, and relevant application permissions.
Choose expiration and revocation behavior based on the product’s needs. A copied “15 minute” value is not a complete session strategy.
Protect sensitive transitions
Changing billing details, granting access, or approving an order deserves a clear confirmation of the action and the authority behind it.
Revalidate relevant state at execution time. A form opened earlier may contain stale permissions, prices, or resource status.
Keep failure behavior understandable. If access is revoked, the system should stop the operation without leaking the protected content in an error message.
Give agent tools their own audience boundary
An agent connector does not inherit unlimited authority from the fact that a user signed in. The MCP authorization specification dated November 25, 2025 requires protected servers to validate that incoming access tokens were issued for them. It forbids forwarding the client’s token unchanged to an upstream API.
Treat the connector as one resource and the downstream service as another. Record the acting user, permitted operation, resource audience, and tenant at the point where the tool executes. Request additional scope only when the intended operation requires it; scope expansion should not become an automatic response to every denial.
For ordinary OAuth integrations, RFC 9700 is the current published security best-practice foundation used in this review. Apply its flow-specific guidance through maintained libraries rather than assembling a new authentication protocol.
Exercise revocation during an operation
A useful test begins with permission to edit a document, then removes that permission after the editor has loaded but before a save or export executes. Test the HTTP route, background worker, and live collaboration connection separately.
Expected behavior should be defined in advance: stop the protected operation, preserve an unsent local draft where appropriate, and return an error that does not reveal another tenant’s record. An old subscription or queued job must not extend access indefinitely.
Also present a valid token intended for a different service in an authorized test environment. Signature validation may pass; audience validation must still reject the request. This distinguishes a working trust boundary from a test that only proves the token parser runs.
Test with two organizations
Create representative users and resources for two tenants. Attempt the same operations across the boundary using ordinary and modified requests in an authorized test environment.
Include list endpoints, search, exports, attachments, and background processing. These paths are easy to overlook when tests focus only on the main detail page.
Record expected denial as a first-class result. A test suite that proves only successful access leaves half the policy unexamined.
Observe without collecting secrets
Security logs should identify the action, resource class, outcome, and enough context to investigate. Avoid recording raw credentials, session tokens, or unnecessary personal data.
Review dependencies and configuration as part of release work, and use the relevant primary standards for compliance obligations. This article does not establish compliance by listing technologies.
A secure design is one whose authority boundaries remain clear under retries, stale state, and ordinary implementation mistakes.
Keep a good idea close.
Follow Signal Tower
