Yes. OAuth apps are delegated identities with consent-based scope, while service accounts are usually provisioned for controlled system-to-system work. The governance model should reflect that difference: consent, review, and reauthorisation for OAuth apps, and lifecycle, privilege, and rotation controls for service accounts. Both still belong in the NHI estate.
What makes OAuth apps and service accounts different operationally?
They are both non-human identities, but they behave differently in governance. OAuth apps usually stand for a delegated integration that acts through user or admin consent, scoped tokens, and revocation paths. service account are normally system identities used for workload or service-to-service access, so the control emphasis shifts toward provisioning, secrets, credential lifetime, and rotation.
That difference matters because the same review process does not fit both. Treating them as the same object often leads to weak consent oversight for OAuth apps or weak credential lifecycle control for service accounts.
For OAuth, the key question is whether the app still needs the access it was granted. For service accounts, the key question is whether the account still exists for a valid system purpose and whether its privileges remain appropriate.
Where governance should diverge for consent, scope, and lifecycle
OAuth apps should be governed like delegated access relationships. Review the consent boundary, the scopes requested, who approved them, and whether the app can be reauthorised or removed without breaking a business process. That makes the governance model closer to access review and consent management than to classic account administration.
Service accounts should be governed like durable system identities. The core controls are ownership, inventory, least privilege, rotation, expiry where possible, and detection of stale or interactive use. Service account security guidance is most useful here because it focuses on discovery, privilege control, and lifecycle discipline rather than consent.
In practice, this means the review cadence can differ. OAuth apps benefit from periodic consent recertification and an explicit decision on whether the integration still deserves trust. Service accounts benefit from scheduled credential review, rotation checks, and ownership verification so that silent persistence does not become normal.
What happens when organisations collapse them into one control model?
When organisations treat OAuth apps and service accounts as interchangeable, they usually miss the failure mode that matters most for each one. OAuth apps are attractive to attackers because a seemingly legitimate consent grant can produce durable delegated access, especially if scopes are broad or tokens are long lived. OAuth app governance helps because it centres on consent, scope, and revocation rather than on password-style account thinking.
Service accounts fail differently. The risk is not consent drift, but unmanaged standing access, forgotten credentials, and lack of rotation or offboarding. If the account survives the system it was created for, it can outlive the business need that justified it, which turns a technical convenience into a persistent access path. Credential rotation challenges show why these accounts need an explicit lifecycle model rather than ad hoc maintenance.
A useful mental model is this: OAuth apps are approvals that can expire; service accounts are assets that can be orphaned. The first is usually a trust problem, the second a hygiene problem, and the controls should follow that distinction.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | OAuth apps and service accounts can persist after business need ends. |
| NHI-05 — Overprivileged NHI | Both OAuth scopes and service-account entitlements can exceed actual need. | |
| NHI-07 — Long-Lived Secrets | Service accounts often depend on credentials that outlive safe operational windows. | |
| Recommendation — Revoke unused non-human identities promptly and verify offboarding removes access. Reduce scopes and privileges to the minimum required for the task. Set rotation and expiry expectations for credentials that enable service access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Service-account credentials need lifecycle, rotation, and revocation controls. |
| AC-6 — Least Privilege | OAuth scopes and service-account permissions should be constrained to needed access. | |
| AU-2 — Event Logging | Reviewing OAuth consent and service-account use depends on auditable activity records. | |
| Recommendation — Manage authenticator issuance, storage, rotation, and revocation for service identities. Limit delegated scopes and service-account entitlements to the minimum necessary. Log consent grants, token use, and service-account activity for review and detection. | ||
Practitioner Guidance
What to verify: For every OAuth app, verify who granted consent, what scopes were approved, and how fast you can revoke access if the integration is no longer trusted. For every service account, verify the named owner, the systems it touches, and whether its credentials are rotated on a schedule that matches the actual exposure window.
Decision rule: If the access is approval-based and revocable without changing the underlying system, treat it as an OAuth governance problem. If the access is an operational dependency for a workload, treat it as a service account lifecycle problem. Do not force both into the same review template.
Common mistake: Teams often audit the app catalog but ignore the token and scope details for OAuth, then over-focus on passwords for service accounts while missing broad permissions or abandoned privileges. The right control set is different because the failure paths are different.
Practitioner takeaway: Separate delegated trust from system ownership. OAuth apps need consent and reauthorisation discipline, while service accounts need inventory, least privilege, and rotation discipline.