Notifications
Clear all
Topic starter
09/07/2026 3:25 pm
TL;DR: Identity teams now have to govern client-side access patterns and session-bound authorization, not just server-rendered admin workflows as WorkOS is exposing a session-aware GraphQL API for browser-side user management, invitations, roles, sessions, passkeys, and MFA so teams can build custom admin surfaces without backend proxying, with future coverage planned for SSO, directory sync, audit logs, and RBAC.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should teams govern identity actions exposed through browser-based APIs?
A: Teams should treat browser-exposed identity actions as governed workflows, not simple UI calls.
Q: Why do session-aware client APIs change IAM risk models?
A: They move part of the identity control experience into the browser while preserving session context, which means the frontend becomes part of the trust boundary.
Q: What do security teams get wrong about custom user management UIs?
A: They often focus on UX and overlook the governance implications of exposing lifecycle actions such as invitations, role changes, and MFA management.
Practitioner guidance
- Classify browser-exposed identity mutations by privilege tier Separate read-only identity queries from mutating operations such as role changes, MFA enrollment, session revocation, and member removal.
- Review origin allowlists and token TTL together Test whether short-lived, origin-pinned tokens are actually constrained enough for the browser workflows you intend to expose.
- Map UI actions to joiner-mover-leaver controls Trace every invite, membership change, MFA enrollment, and session revocation action back to the lifecycle process it implements.
What's in the full announcement
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The exact browser token minting flow and origin-pin mechanics for session-aware API calls.
- The full query and mutation surface for user management, memberships, invitations, MFA, and session controls.
- The rollout plan for SSO, Directory Sync, audit logs, RBAC, feature flags, Pipes, API keys, and Vault.
- The access path for closed early access teams that want to test custom admin surfaces before general release.
👉 Read WorkOS's session-aware GraphQL API details for custom user management →
Session-aware GraphQL for user management: what changes for IAM teams?
Explore further
09/07/2026 3:44 pm
Custom identity admin is becoming a client-side governance problem: once user management, invitations, roles, and session controls are exposed to the browser through a session-aware API, the security model has to govern where identity decisions are made, not just who is allowed to make them. That means the boundary between application UI and identity control plane becomes a policy boundary, not merely a design choice. Practitioners should treat frontend-exposed identity operations as governed workflow surfaces, not convenience endpoints.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: What frameworks should apply to browser-exposed identity workflows?
A: NIST CSF 2.0 and NIST SP 800-53 Rev 5 are the most useful anchors when browser-accessible identity operations affect access control, authentication, and auditability. Teams should map the exposed mutations to control families for access, identification, and logging rather than treating them as purely application-layer concerns.
👉 Read our full editorial: Session-aware GraphQL changes custom user management UI design
