What is the difference between a service account and an OAuth-connected app?

How a service account differs from an OAuth-connected app

A service account is usually created as the identity for a system, job, or integration that needs to act on its own. An OAuth-connected app is typically not a separate user in that sense, it is a delegated client that gains access through consent and scoped authorization. The practical difference is who is being authenticated, how access is granted, and how broad the resulting blast radius can become.

That distinction matters because the access model drives both governance and failure mode. A service account is usually managed as a workload credential with direct permissions, while an OAuth-connected app depends on grants, scopes, refresh behaviour, and the trust placed in the app itself. If you treat them as interchangeable, you can miss where privilege actually lives and how it should be reviewed.

Where the security boundary actually sits

The key question is whether the system is acting as itself or acting on behalf of someone else. A service account is normally tied to one workload or process, so its access can be bounded around that task. An OAuth-connected app often inherits access from a user or admin consent flow, which means the application can carry delegated rights across tenants, mailboxes, files, APIs, or business data depending on the scopes approved.

That is why inventory and purpose matter. Service Account Security Guide is useful when you need to distinguish direct workload access from human-driven approvals, because the operational questions are different: who owns it, what can it reach, how is it rotated, and what happens when the workload is retired. For OAuth-connected apps, the more relevant question is which permissions were consented to and whether those scopes are still justified.

OAuth also has a narrower protocol story than many teams assume. The app is a client in an authorization framework, not automatically a trusted application by virtue of being installed. RFC 6749: The OAuth 2.0 Authorization Framework defines that delegation model, including the client credentials flow often used for machine-to-machine access, while RFC 9700: Best Current Practice for OAuth 2.0 Security captures the current hardening guidance around token theft and sender-constrained tokens.

Why the blast radius is often different

Service accounts usually fail through overprivilege, stale secrets, or poor lifecycle control. The damage is often concentrated in whatever that one workload can reach. OAuth-connected apps can have a wider and less obvious blast radius because a single consented app may inherit access to multiple resources, and those grants can persist through refresh tokens or long-lived authorizations if no one revisits them.

That is why connected-app review should focus on consent scope, publisher trust, and whether the application still needs the access it already has. The NHIMG SaaS-to-SaaS and OAuth App Governance Guide is the better navigation path when the concern is consent, scope hygiene, and revocation discipline. When the concern is compromised tokens or third-party abuse, the problem shifts from “what is the app” to “what can the app already do if its grant is abused.”

That risk is easiest to see in real incidents. Microsoft verified publisher OAuth phishing 2022 shows how malicious apps can convert consent into persistent access, while ShinyHunters Salesforce data theft campaign 2025 shows how approved connected apps can be used to export data at scale once consent is obtained.

Risk and Threat Considerations

OAuth-connected apps are attractive to attackers because consent can be easier to obtain than direct credential theft, and the resulting access can look legitimate to the target platform. Service accounts are attractive because they can hold direct privileges, automation access, or durable secrets that are hard to notice when they are stale or widely reused.

Failure mechanism: Overbroad scopes, stale grants, or unmanaged workload credentials create a trust path that survives the moment of setup. Once a consented app or service account is abused, the attacker can operate with the identity's normal permissions until the grant or credential is revoked.

Impact: The resulting exposure can include mailbox access, file export, API abuse, data theft, or lateral movement into adjacent SaaS and cloud services. In practice, the larger the scope or the longer the credential lifetime, the more the compromise resembles an organisation-level access problem rather than a single account problem.

Practitioner Guidance

What to verify: Verify whether the integration is a direct workload identity or a delegated OAuth client, then map the actual permission path rather than the label in the admin console. If the access is consent-based, review scopes, refresh-token behaviour, and who can grant or re-consent the app.

Decision rule: If the object can act without a human present, treat it as workload access and manage its lifecycle, ownership, and rotation accordingly. If it can access user or tenant data through consent, treat it as a delegated trust relationship and review it like any other privileged integration.

Practitioner takeaway: The important difference is not just technical form, it is authority source. Service accounts should be governed as bounded workload identities, while OAuth-connected apps must be governed as delegated access paths whose real risk is scope, persistence, and revocation speed.

Related resources from NHI Mgmt Group

• Guide: SaaS API Token Security Guide
• Who should own OAuth app and service account cleanup?
• What are the implications of using OAuth tokens in third-party integrations?
• Why is OAuth token management critical in cloud environments?
• What makes OAuth tokens risky in NHI environments?