Before Splitting Services, Audit Who Can Act for Whom

A service split changes who makes access decisions, even when the login screen stays the same. Before moving an export endpoint into its own service, establish how it knows which user may export which team’s report. If that answer is ‘the old application already checked,’ you have found an architecture dependency, not a migration plan.

A service boundary is an authorization boundary

Consider a proposed reporting service. Today, the application loads a report through a query that joins it to the user’s team. After extraction, the reporting service accepts a report ID from the gateway and fetches the report directly. The user is authenticated in both designs; only the first design proves that this user may access that report. This is a hypothetical failure mode, but it is exactly the kind of assumption a service split can expose.

Keep four questions separate. Authentication establishes who the user is. Workload authentication establishes which service is calling. Authorization decides whether a subject may perform a specific action on a specific resource. Delegation establishes whether a service is acting for a user, and under what limits. A valid service credential cannot answer the resource question by itself: SPIFFE workload identities can authenticate a workload, but do not establish its right to a user-owned report.

This is why moving a login check or putting authentication at the gateway is insufficient. OWASP’s authorization guidance calls for identifying subjects, resources, operations and trust boundaries, denying by default, and checking permission on the specific object for every request. Its microservices guidance says protected services must enforce access on internal calls too. A gateway can reject unwanted ingress; it cannot decide every tenant- or object-specific rule on behalf of a service that owns the operation.

Do not infer from this that every team needs a central policy platform. A single application with a few roles may be better served by explicit checks backed by its primary database. The immediate requirement is to make the decision visible and testable before changing the boundary.

Trace one sensitive request, including the paths users never see

Pick one workflow with real consequences: a user exporting another team’s report is a useful test because the expected answer is denial. Trace it from login through the gateway, reporting endpoint, data read, export worker, download and audit event. At every hop, record the authenticated user, calling workload, tenant, requested action, report owner, source of the ownership fact, and component that enforces the decision.

Then trace how the same operation might bypass the happy path. Can an internal caller invoke the reporting service directly? Does the worker receive a report ID without the original user context? Can it retry after the user loses access? Does the download endpoint recheck permission, or assume that creation of an export permanently authorizes retrieval? These questions distinguish a diagram of services from a map of effective permissions.

Build a decision table for the proposed boundary. Give it rows for an owner requesting their report, a member of another team requesting it, an internal service calling without a user, and a request with a valid credential but the wrong token audience. For each row, specify the expected allow or deny result, where enforcement occurs, which data is authoritative, and what evidence will show that the check ran. Include a direct-to-service request as well as a gateway request.

A code audit can locate checks and missing branches, but code alone cannot prove what production currently permits. Configuration may change routing and token validation; runtime traces may reveal callers absent from the repository; workflow owners may know how accounts are granted and removed. Treat discrepancies between those sources as assessment findings, not details to smooth over.

Audit owners as carefully as endpoints

Authorization depends on ownership data that may not look like security infrastructure. Find where team membership, report ownership, grants, delegation and expiry actually live. Identify who may change each record, which services consume copies, and whether a historical question—‘who could export this report at that time?’—can be answered from durable evidence rather than today’s state.

Do the same for non-human principals. Inventory service accounts, the people accountable for them, granted resources, credential stores, rotation responsibilities and attestation responsibilities. Check what happens when an owner changes teams or leaves. An account without a current accountable owner needs investigation; renaming the application that uses it does not fix its lifecycle.

A November 2026 IAM rebuild account describes modeling people, service accounts, resources, ownership, expiry and attestation history together. Its reported population is roughly 80,000 people who own service accounts—not 80,000 service accounts. The useful lesson is the relationship between identity and accountability, not a prescribed graph database, event pipeline or API stack. SQL can represent ownership, validity and history too, provided the model and queries support the decisions the system must make.

Ask two different questions of that model. Can it decide whether access is allowed now? And can it reconstruct the relevant grant, owner and policy inputs for a past decision? A current-state lookup does not automatically provide historical evidence. If an export dispute requires the latter, plan for it before records are moved or overwritten during decomposition.

Choose what crosses the service boundary

When one service calls another, distinguish the calling service from the user for whom it acts. OWASP’s identity-propagation guidance allows forwarding an external access token when each recipient is an intended audience and can validate it. If a downstream service needs a different audience or explicit delegation, token exchange is an option—not an automatic requirement for every hop.

RFC 8693 defines token exchange using a required subject token and optional actor token, audience and scope. Retaining the actor’s identity matters when the downstream service needs to know both whose access is being used and which workload initiated the call. The issuer must authorize and constrain the exchange: merely requesting a narrow scope does not guarantee narrower privileges. Exchange also does not revoke the input token or automatically link the output token to its revocation. Whatever mechanism you choose, RFC 9700 recommends limiting access tokens to necessary privileges and intended resource servers; recipients must verify that a token was meant for them.

Policy placement is a separate decision. Shared policy definitions can reduce inconsistent rules, while a remote decision service adds latency and an availability dependency. AuthZEN Authorization API 1.0 defines an evaluation interface using subject, action, resource and optional context; it does not dictate where a team must run its policy engine. Each protected service still needs an enforcement point and a deliberate answer for unavailable policy inputs. Decide whether it denies, uses a bounded cached decision, or has another explicitly approved behavior. Do not let a network timeout silently become permission.

Measure revocation where it becomes real

Set a business-specific maximum between the moment access should be withdrawn and the moment the last relevant service rejects a representative request. Measure the owner workflow as well as technical propagation. In the IAM rebuild account, consolidating attestation, rotation and vaulting into one owner workflow reportedly reduced end-to-end revocation from about three days to under one day. That is one organization’s result, not a target another architecture will automatically meet.

A published update is not the same as an effective denial. OWASP’s policy and data distribution guidance recommends identifying authoritative sources and maximum acceptable update delays. Test delayed and missed events, stale relationship replicas, decision caches, unavailable policy inputs, locally validated tokens and already-issued downstream tokens. A cache’s maximum age alone is not a universal revocation bound.

Run the test against each path found in the request trace, including exports already queued and direct calls to the new service. Start the clock when access should be removed; stop when the last relevant path denies it. If the team cannot observe those endpoints or produce a representative denied request, record the revocation requirement as unverified rather than reporting only event-delivery latency.

Make the split decision with a bounded pilot

For each candidate boundary, compare three options before committing to infrastructure. First, keep the current boundary and fix object-level checks in place. Second, extract a narrow capability while preserving authoritative ownership data and explicit enforcement. Third, introduce shared identity or policy infrastructure if repeated cross-service decisions justify its operational cost. Prefer the least disruptive option that meets the required denial and revocation behavior; a service split is not itself a security improvement.

Use this decision checklist for the pilot:

• Evidence: Produce an identity-and-authorization map, reproducible permission findings, named owners for policy and ownership data, and a list of assumptions that still need runtime verification. An independent code audit and technical assessment can frame that diagnosis and prioritize a migration roadmap; specify penetration testing or compliance assurance separately if you need either.

• Acceptance tests: Exercise cross-tenant access, direct-to-service calls, workers, downloads, wrong-audience tokens, missing ownership data and withdrawal of an existing grant. Verify denial at the protected service, not only at the gateway.

• Operational conditions: Define the measured revocation limit, expected behavior when policy inputs are unavailable, token lifetimes, and the teams responsible for credential and grant changes.

• Rollback: Decide what evidence will stop the pilot and how the old route can be restored without creating two conflicting sources of authority. Rehearse the bounded migration and rollback; the approach to a legacy modernization pilot is useful here.

If the pilot cannot identify an authoritative owner for a resource or show where its permission is enforced, pause the extraction. Fixing that ambiguity in the existing system is a smaller and safer modernization step than distributing it across new services.