Verify signed service calls
On the signed application-configuration route, the manager verifies a platform service against its published public key. The issuer and intended recipient are checked alongside the signature.
Example — Give platform services their own identity
The scheduler retrieves managed application configuration from the platform manager with its signed token. The manager verifies the claimed service, intended recipient and signature before accepting the request.
For engineers
Platform initialization provisions each service’s keypair and publishes the matching public key in platform configuration. The private key belongs to the signing service’s environment. The framework-managed registry makes missing signing materials part of synchronization rather than a manual key-copy task.
On receipt, the manager checks that the token issuer matches the service identity in the request, resolves that service’s published key and verifies the token:
Selected source from apps-to-manager.apps-manager.platform.controller.ts:
await this.jwtService.verifyRaw(token, publicKey, {
// Validate issuer matches the serviceId
issuer: jwtServiceId,
// Audience should be apps-manager for platform-to-platform requests
audience: PlatformApplicationType.PLATFORM_APPS_MANAGER,
});
This selected verification call is from apps-to-manager.apps-manager.platform.controller.ts. Its surrounding path refuses an unrecognized service or missing public key. The published configuration is the verification authority; it does not silently fall back to a second environment key.
The platform-service credential retrieval route is different: it authenticates a shared platform secret and looks up the supplied registered service ID. Do not extend the signed route’s caller-to-key binding to that shared-secret route.
Keep application authentication separate
An application runtime presents its platform secret through the application door. The manager resolves the presenting runtime principal from that credential rather than trusting a principal name supplied by the caller.
A service token proves service identity and audience. The endpoint still decides what that service may do; it is not a user session or a general authorization grant.
Coordinate a key change
When rotating, distribute the private half to the signing service and publish the corresponding public half for verifiers. A mismatch is an authentication/configuration failure with a republishing remedy, not a reason to weaken verification. In local environments, wildo local init republishes platform configuration from the secret store.