Overview#
Argus is a fleet of applications: PSAP consoles, investigation workspaces, workforce tools, evidence systems, and native mobile clients. Operators cross those boundaries constantly. Each hop that demands another password, another SSO dance, or a brittle URL carrying readable identity claims costs time and creates security review findings. Integrators building partner or utility portals face the same problem when they need a signed-in Argus user to arrive in a second service with tenant and authority intact.
Opaque Service Handoffs are short-lived, single-use handles issued by auth_service for a named destination service. The source application requests a handoff for the current user. The client presents that opaque handle to the destination. The destination consumes it once, receives a projection of the session context it needs, and establishes its own session. Replay is rejected. Expired or destination-mismatched handles are rejected. Concurrent consume attempts resolve so only one winner succeeds. Nothing sensitive needs to travel as a legible identity blob in a query string.
For enterprise buyers comparing Argus to suites that either force a single monolithic web origin or accept weak cross-app deep links, this contract is how a modular architecture still feels like one signed-in platform.
Last Reviewed: 2026-09-15 Last Updated: 2026-09-15
Key Features#
-
Opaque by design: The handle is a reference, not a packed JWT of profile data meant to be inspected by intermediary UI. Destination services redeem through auth_service rather than decoding marketing-shaped tokens in the browser.
-
Single-use consumption: Each handoff can be consumed only once. Tests cover replay after success and concurrent double-consume races so two tabs cannot mint two sessions from one handle.
-
Destination binding: Issue names the service allowed to redeem. A handoff minted for workforce cannot open an unrelated admin surface. Mismatch fails closed with a generic invalid-handoff response suitable for public clients.
-
Short time to live: Handles carry a tight TTL in the platform cache so abandoned redirects age out quickly.
-
Tenant-aware projection: Optional tenant normalisation keeps redeem aligned with the organisation context the operator was working in, reducing cross-tenant landing bugs during multi-tenant operations.
-
Audited issue and redeem: Issue and consume actions are recorded for security review, including rejected attempts, so SOC and compliance teams can trace cross-app movement.
-
Web and native continuity: The same handoff family supports browser applications and native mobile clients that redeem into the native mobile session contract, including workforce and responder apps.
-
Scoped service permissions: Service identities that issue or consume handoffs require explicit grants such as
auth:service-handoff:consume, keeping the capability inside the RBAC catalogue rather than as an unauthenticated convenience endpoint.
Use Cases#
-
Console to console navigation: A supervisor moves from operations into payroll close, case tools, or a specialised utilities workspace without re-entering credentials and without copying session cookies across unrelated origins by hand.
-
Desktop to mobile continuation: An operator starts work on a workstation and continues on a handset. The mobile client redeems a handoff into the native session contract instead of collecting a password on a phone keyboard in the field.
-
Partner and utility entry points: Separately deployed partner portals can join the handoff contract so specialised tools remain independently releasable while still living inside the Argus sign-in boundary.
-
Break-glass and step-up adjacent flows: When a destination requires a fresher assurance level, handoffs compose with passkey step-up and session policies already enforced by auth_service rather than inventing a second login product.
-
Security questionnaire evidence: Single-use, destination-bound, audited cross-app transfer is a concrete answer to reviewers who reject long-lived bearer tokens embedded in URLs.
Integration#
Opaque Service Handoffs are implemented in auth_service (service_handoffs issue/consume paths, API endpoints, Valkey-backed handle storage, and automated tests for replay and races). Consuming applications request a handoff when navigating across services and redeem before rendering protected UI. Native responder and workforce clients redeem into service-owned cookies under the Native Mobile Session Contract. Pre-provisioned service identities include the consume grant where appropriate.
Failed redeem should fall back to the normal sign-in path for that destination. Product UI should treat invalid handoff as an expected edge (expired link, reused link), not as a silent blank page.
Open Standards#
- OAuth 2.0 (RFC 6749): Handoffs sit beside platform OAuth/OIDC flows and inherit client and redirect discipline.
- OAuth 2.0 Token Exchange (RFC 8693): The issue and redeem pattern follows the token-exchange model for moving authority between services without re-prompting the user.
- JWT Profile for OAuth 2.0 Access Tokens (RFC 9068): Where downstream APIs need structured access tokens after redeem, minted tokens can follow the JWT access-token profile.
- RFC 9700 (OAuth 2.0 Security Best Current Practice): Single-use, short-lived, audience-bound artifacts align with current OAuth security guidance for cross-application transfer.