Topic · DiggingBeagle record
Cross-session authorization
Authorization controls that bind asynchronous jobs, messages or results to the client or session that created them.
- Topic kind
- pattern
Definition & limits
An identifier locates an object; an authorization decision determines who may use it. In a multi-client service, list, fetch, cancel and message-consumption operations can expose another client’s work when they check only that the object exists.
The recurring design problem
Asynchronous tasks make ownership easy to lose between creation and later retrieval. A task can outlive a transport connection, and queued messages can be consumed as well as read. Review the authenticated principal, its relationship to the task and the policy for every operation rather than assuming that an opaque ID or a logged-in connection is sufficient.
Canonical example and limit
The MCP Python SDK task advisory documents this problem in an opt-in experimental feature. Its patch automatically protects the SDK-generated task-ID path; custom IDs and handlers require separate review. This example is not evidence that every MCP server or asynchronous task implementation is affected.
What to test
Create an object as A and exercise each operation as B, including listing, message consumption, reconnection, cancellation and error handling. Decide explicitly whether authority follows a principal, a session or a deliberately designed capability. The test is an implementation review method, not a claim that this publication independently executed every path.
Distinguish adjacent failures
Localhost trust concerns which callers can reach a service; cross-session authorization concerns which objects an admitted caller may use. Fixing admission does not resolve owner-blind operations, and fixing object ownership does not validate executable parameters.
Examples
- MCP Python SDK experimental tasks lacked creator-session binding in affected versions.