Enterprise authorization · Run 004
Revocation is a control, not replay protection.
A bounded localhost experiment tested whether explicit access-token revocation propagated across two independent protected-resource instances.
Published 24 October 2026The boundary that matters
MCP authorization binds authorization and token requests to the intended resource and requires the server to validate presented access tokens.[1] Enterprise-Managed Authorization adds an IdP-mediated ID-JAG exchange before the MCP authorization server issues a resource token.[2]
Those controls establish who may receive a token and where it may be used; they do not, by themselves, make a copied bearer token single-use. Step-up authentication is a separate control surface: RFC 9470 defines challenge/retry vocabulary for authentication strength and recentness, while the resource server supplies the policy deciding what is sufficient.[3] Protected-resource guidance recommends audience-restricted tokens when a client interacts with multiple resource servers.[4]
One-time ID-JAG use, access-token revocation, audience binding and sender-constraining are separate controls. They need separate evidence.
What was tested
The topology used five task-owned processes: a Python IdP, a Node resource authorization server, two independent Node protected-resource listeners, and the pinned Inspector test process. Both protected resources introspected bearer tokens at the same shared resource authorization server.
The Inspector EMA client was pinned to commit ae865a19178ddf6f375780a02e9c77c4cf4da184, the exact source used by the archived integration harness.[5] The first flow completed authorization, EMA, resource-token redemption, MCP initialization, tool discovery and a protected tool call.
- Capture the bearer resource token.
- Call both protected resources with it.
- Revoke it at the shared resource authorization server.
- Introspect and call both resources again.
- Run a fresh Inspector EMA flow as a control.
Results
| Check | Observed result |
|---|---|
| First Inspector EMA flow | Connected, authorized, protected_read observed |
| Introspection before revocation | active: true |
| Primary resource before revocation | HTTP 200 |
| Secondary resource before revocation | HTTP 200 |
| Revocation endpoint | HTTP 200 |
| Introspection after revocation | active: false |
| Primary resource after revocation | HTTP 401 invalid_token |
| Secondary resource after revocation | HTTP 401 invalid_token |
| Fresh Inspector EMA flow | Connected, authorized, protected_read observed |
| Machine assertions | 8/8 true; one Vitest test passed |
Interpretation
The same bearer token was accepted twice before revocation. That is the control result that prevents overclaiming: centralized revocation stopped the token after the decision, but did not make the bearer token single-use or sender-bound while it remained active.
For an enterprise control plane, “revocation works” should be reported as a time-bounded propagation property: which authority revokes, how resource instances learn the decision, what happens under cache staleness or partition, and how fresh authorization behaves afterward.
With shared introspection and explicit revocation, two independently running protected-resource instances rejected a revoked bearer token while a fresh EMA authorization remained usable; before revocation, the bearer token remained replayable.
Limits
Task-owned localhost services only; no production deployment evidence.
External IdP, TLS, DCR, key rotation, distributed revocation state, cache staleness, partitions and authorization-server replication.
No sender-constraining or automatic bearer-replay detection was tested.
This is explicit cross-instance revocation evidence, not enterprise readiness or a universal MCP property.