Notifications
Clear all
Topic starter
06/06/2026 11:30 am
TL;DR: Multiple applications are now treated as first-class objects with per-app client IDs, session policies, redirect handling, and shared identity across web, mobile, and desktop surfaces, according to WorkOS. The governance shift is real because one identity layer now has to express distinct platform risk, lifecycle, and session expectations without fragmenting users or controls.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should teams govern authentication across web, mobile, and desktop apps?
A: Treat each surface as its own application context even when the same users and organisations are shared.
Q: Why does shared identity across multiple apps create governance risk?
A: Shared identity reduces fragmentation, but it can hide policy drift when each surface behaves differently.
Q: What breaks when session policy is global instead of per application?
A: A single session rule forces one client to inherit another client’s risk profile.
Practitioner guidance
- Model each client as a governed application object Assign separate client IDs, redirect URIs, and session policies to each web, mobile, and desktop surface so authentication is controlled by context rather than by one shared default.
- Review session lifetimes by surface Set longer-lived sessions only where the user case justifies them, such as mobile, and keep web sessions tighter where reauthentication risk is higher.
- Synchronise recovery and invitation flows Test password resets, invite links, and sign-in redirects across every application to ensure users return to the correct surface without manual correction.
What's in the full announcement
WorkOS's full post covers the implementation detail this analysis intentionally leaves for the source:
- Per-application configuration examples for client IDs, redirects, and session policies across different surfaces
- Operational guidance for keeping users and organisations shared without duplicating account state
- Support and impersonation workflow details for teams that need access across multiple applications
- Platform-specific credential handling considerations for web, mobile, and desktop clients
👉 Read WorkOS's explanation of multiple app authentication and shared identity →
Multiple app authentication: what it means for IAM teams?
Explore further
06/06/2026 12:20 pm
Per-application authentication is really per-surface identity governance. Once a product spans web, mobile, and desktop, the real control boundary is no longer the user account. It is the application context in which that account is expressed. That changes how teams think about redirect handling, session duration, and client credentials because each surface carries different risk and usability assumptions. The practical conclusion is that governance has to move from product-level defaults to surface-level policy.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most environments cannot prove where non-human access is actually living.
A question worth separating out:
Q: Who should approve support impersonation across multiple applications?
A: Support impersonation should be treated as privileged access and approved under the same governance model used for other elevated actions. That means explicit logging, role scoping, and periodic review. The control goal is to keep support access tied to a specific app and a specific case, rather than letting it become a standing administrative capability.
👉 Read our full editorial: Multiple app authentication changes how teams govern shared identity
