Treat each surface as its own application context even when the same users and organisations are shared. Separate client IDs, redirect URIs, and session policies keep the experience consistent while allowing security controls to differ by risk. The important part is maintaining one identity source of truth so lifecycle events and account state stay aligned across all apps.
Why This Matters for Security Teams
Web, mobile, and desktop apps often share customers but not the same trust profile. A mobile app may need stronger device binding, a desktop app may integrate with local resources, and a web app may rely on browser-session controls and redirect handling. Treating them as one “client” usually creates fragile exceptions, weak logout behaviour, and inconsistent token handling. Current guidance suggests aligning identity governance to the application context, not to the user alone, while preserving a single source of truth for account state and lifecycle. That approach fits the broader principles in the NIST Cybersecurity Framework 2.0 and the lifecycle emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
Teams also tend to underestimate how quickly a single mis-scoped client registration can create cross-platform access drift. If refresh tokens, redirect URIs, or consent policies are shared too broadly, a compromise in one surface can affect the others. In practice, many security teams encounter that drift only after an audit finding or incident review, rather than through intentional design.
How It Works in Practice
Each app surface should have its own client registration, redirect URI set, token audience, and session rules. That does not mean creating separate identities for the same person. It means issuing distinct application credentials so the web app can enforce browser-safe flows, the mobile app can use platform-specific protections, and the desktop app can apply local-device controls without weakening the others. This is especially important when sign-in uses OIDC or similar federated patterns, because the application should prove what it is before it receives tokens meant for that surface.
Security teams usually get the best results by combining a shared identity provider with surface-specific policy. For example:
- Use separate client IDs so each app has its own token audience and consent boundary.
- Bind redirect URIs tightly, especially for native apps and desktop apps with local callbacks.
- Shorten web sessions where browser risk is higher, while allowing different re-authentication intervals on mobile or desktop.
- Keep account lifecycle events centralised so disablement, recovery, and step-up requirements apply everywhere.
That model maps well to the governance concerns highlighted in Top 10 NHI Issues, especially when client secrets, refresh tokens, or embedded credentials are stored too broadly. It also aligns with the identity assurance focus of NIST Cybersecurity Framework 2.0, which pushes teams to govern access according to risk and asset context rather than uniform treatment. These controls tend to break down when legacy desktop software cannot support modern token exchange or when shared embedded secrets are copied across build pipelines, because the same credential then governs too many surfaces at once.
Common Variations and Edge Cases
Tighter per-app governance often increases operational overhead, requiring organisations to balance security isolation against release complexity. That tradeoff is real, especially for smaller teams that want one login flow across every surface. Best practice is evolving, but current guidance still favours separate app registrations whenever the trust boundaries differ in meaningful ways.
Edge cases usually involve native apps, kiosk-style desktop tools, or partner-distributed software. Native mobile apps may need stronger runtime protections and narrower token lifetimes, while desktop apps can require device posture checks or certificate-based trust. Kiosk and shared-device scenarios often need more aggressive session timeout and re-authentication rules than a standard consumer web app. For iOS-specific secret handling risks, the IOS app secrets leakage report is a useful reminder that “same identity, different surface” still requires different storage and runtime assumptions. For audit readiness, the Ultimate Guide to NHIs — Regulatory and Audit Perspectives is helpful for framing evidence collection around account state, token scope, and revocation. The practical rule is simple: one identity source of truth, many application-specific controls, and no shared credential pattern that cannot be revoked cleanly per surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Separates access governance by application context while preserving least privilege. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Client registrations and tokens are NHI assets that need distinct governance. |
| NIST SP 800-63 | AAL2 | Different app surfaces may require different assurance and reauthentication strength. |
Treat each app client as a managed identity asset and scope secrets, redirects, and rotation per surface.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
