A browser-assisted authentication pattern used by desktop or local applications that need to complete an authorization step interactively. It is useful for setup and testing, but it still depends on a human present at least once, which makes it less suitable than non-interactive workload identity for production automation.
How Installed Apps Use the OIDC Flow
Installed apps use OpenID Connect as a browser-assisted sign-in pattern when a desktop or local application must ask a user to authenticate interactively, then receive tokens back from the authorization server. The flow is designed for apps that cannot safely embed a secret or handle a full web login the way a server-side application can.
In practice, the app launches or opens a browser, sends the user to the identity provider, and waits for the resulting authorization response. That makes the pattern convenient for setup, first run, and testing, but it also makes the user present in the loop, which is why it is not the best fit for unattended production automation.
Why This Pattern Exists
The installed-app OIDC flow exists to give native software a standards-based way to obtain user identity without pretending to be a confidential web application. It is especially useful where the app needs only occasional interactive login, for example a desktop admin tool, a developer utility, or a local client that should not store long-lived credentials.
The key design choice is to move the sensitive part of authentication into the browser and identity provider, while the app receives only the resulting authorization artifact. OpenID Connect Core 1.0 defines that authentication layer on top of OAuth 2.0, which is why this pattern is often discussed as a login flow rather than a pure API access flow.
Because the browser and identity provider handle the interactive step, the app can avoid collecting passwords directly. That reduces exposure compared with older embedded-credential patterns, but it does not remove the need to protect redirects, token handling, and local session storage.
How It Differs From Non-Interactive Workload Identity
For real automation, the important difference is not cosmetic, it is operational. An installed app flow assumes a human can complete sign-in at least once, while workload identity is built for machine-to-machine access without that dependency.
That distinction matters when deciding how an app should authenticate after setup. If the app needs recurring unattended access, a browser-mediated user login becomes a brittle dependency and a poor control choice. For that reason, the broader NHI guidance around NHI authentication patterns is usually the better model for background jobs, integrations, and services.
The same boundary is why installed-app OIDC is commonly acceptable for developer tooling but not for scheduled production tasks. It is a human-entry pattern first, not a durable automation identity pattern.
Security Characteristics and Failure Modes
Installed apps sit in a less controlled environment than server applications, so the main security issue is not the protocol name, it is the trust placed in the local client and its redirect handling. If the app mishandles the browser return, exposes tokens on disk, or relies on weak local storage, the login flow can become a path to token theft or session replay.
Another important failure mode is mistaking the installed-app flow for proof that the software itself is trusted. The user may be authenticated, but the local app still needs to be treated as an untrusted client that can be inspected, instrumented, or modified on the endpoint. That is why identity provider hardening and federation monitoring remain relevant, even for apparently simple desktop sign-in patterns. Identity Provider and SSO Security Guide is useful background for those trust boundaries.
In OAuth terms, the flow must be handled with the same care as any token-bearing login process. RFC 6749: The OAuth 2.0 Authorization Framework remains the core reference for how authorization grants and client behavior are meant to work, even when the application is native.
Where It Fits in a Modern Identity Strategy
Installed-app OIDC is best understood as a transitional or bounded-use pattern, not a universal identity solution. It fits when a person is in the loop, the software is local, and the authentication event is occasional. It becomes the wrong pattern when the business requirement is continuous unattended execution, delegated service access, or scalable automation.
That is also why identity teams often separate browser-assisted sign-in from service identity governance. The first is about interactive user authentication, the second is about durable machine access, privilege, and lifecycle control. For that broader view, IAM and IGA Basics provides the governance context, while Ultimate Guide to NHIs explains why non-interactive workloads should not inherit human-style login assumptions.
For teams designing desktop clients, the practical question is whether the app is merely a user-facing frontend or whether it is actually acting as a persistent actor in production. If it is the latter, the installed-app flow is usually a sign that the wrong identity pattern is being used.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Installed apps authenticate outside the web server context and need controlled token handling. |
| IA-5 — Authenticator Management | The flow depends on protecting tokens, refresh material, and local credential handling. | |
| Recommendation — Use IA-9 to authenticate native clients through vetted browser and token-handling patterns. Apply IA-5 to protect issued tokens and rotation-sensitive credential material in native clients. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Installed-app OIDC relies on identity federation, browser mediation, and authenticators defined in the guidelines. |
| Recommendation — Align native-app sign-in with phishing-resistant and browser-mediated identity guidance. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Native app OIDC depends on secure browser-based authentication and redirect handling. |
| NHI-07 — Long-Lived Secrets | The pattern is often chosen to avoid embedded secrets, but token persistence still matters. | |
| Recommendation — Review native-app login paths for insecure authentication and redirect handling weaknesses. Avoid long-lived secrets in installed apps and prefer short-lived, bounded credentials. | ||
Related resources from NHI Mgmt Group
- How should security teams handle OIDC client secrets in production apps?
- How should security teams choose between API keys, Device Flow, and Client Credentials for CLI apps?
- Why do OAuth and OIDC matter more when SaaS apps support AI agents?
- Why do installed apps create poor evidence for software spend decisions?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
