OAuth vs. Service Accounts — Q&A

Q. Is OAuth used for individual users or service accounts?
A. OAuth is primarily used for individual users to authenticate and grant delegated access to applications. The access token you receive represents the user and the permissions (scopes/claims) they granted.
Q. What is a service account?
A. A service account is a non-human identity used by software (e.g., a backend or job) to authenticate to another service. It typically uses client credentials or a signed JWT, and it has fixed roles/permissions configured in the target system. It does not inherently represent a user.
Q. How do user OAuth tokens and service accounts work together in a mixed flow?
A. Common pattern:

  1. A human user signs in via OAuth → your app receives a user access token.
  2. Your backend then needs to call a second API that only accepts service account credentials.

To bridge these, you either use impersonation/on-behalf-of or handle the mapping in your own backend logic (details below).

Q. How does the user account map to the service account in that flow?
A. There are two standard approaches:

  • 1) On-Behalf-Of (OBO) / Impersonation / Delegation
    Your backend exchanges the user’s token (with appropriate scopes/consent) for a service account token that acts on behalf of that user.
    Examples: Domain-wide delegation (Google), OBO flow (Microsoft Entra ID).
    Pros: End-to-end user context preserved; clean auditing (“service acted as user”).
    Requirements: The identity platform and target API must support OBO/impersonation; admin consent and specific scopes/roles are usually required.
  • 2) Backend Mapping (Application-level)
    Your backend authenticates to the second API using its own service account and enforces authorization based on the authenticated user from step 1. You pass user identifiers in request metadata/headers or embed them in audit logs, but the token to the second API represents the service, not the user.
    Pros: Works even when the target API doesn’t support delegation; simpler to implement in heterogeneous systems.
    Considerations: You must implement strict authorization checks and robust auditing (e.g., include user ID, tenant, and request ID for traceability).
Q. Which approach should I choose?
A. Prefer OBO/impersonation when the target platform supports it and you need accurate user-level auditing/permissions. Use backend mapping when delegation isn’t supported or when your service needs uniform server-to-server access while still enforcing user-level authorization internally.
Q. Any security best practices for either model?
A.

  • Use least-privilege scopes/roles for both user tokens and service accounts.
  • Separate duties: don’t reuse the same service account for unrelated workloads.
  • Propagate user context safely (user ID, groups/roles) and log correlation IDs for audit trails.
  • Rotate service account credentials/keys; prefer short-lived tokens and managed identities where available.