Join our Newsletter — 33% off our NHI Course

What is the difference between OAuth and JWT in a modern API architecture?

OAuth is an authorization framework used to delegate access to resources without sharing credentials. JWT is a token format used to carry signed claims between parties. OAuth governs permission flow and access control, while JWT governs how identity or claim data is packaged and verified. They can work together, but they solve different problems.

Why This Matters for Security Teams

In modern API architectures, OAuth and JWT are often used together, but confusing them leads to weak trust boundaries and brittle integrations. OAuth decides whether a client can call an API and under what scope; JWT decides what claims are carried and how the receiver verifies them. That distinction matters because a signed token is not automatically a permission model, and a permission model is not automatically a secure token format.

This confusion shows up in incident reviews when teams treat any bearer token as interchangeable, or assume that a valid JWT means the caller should be trusted across services. NHIMG research on the State of Non-Human Identity Security found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which illustrates how delegated access can become opaque fast. Real-world breaches such as the Salesloft OAuth token breach and Klue OAuth Supply Chain Breach show how delegated access can be abused when token handling, consent, and scope governance are not tightly controlled. In practice, many teams discover the difference only after a token misuse event has already exposed data.

How It Works in Practice

OAuth sits at the authorization layer. It is the framework for consent, delegation, scopes, and token issuance flow. A user or workload grants a client limited access to an API, and the API accepts that delegated access based on the token presented. JWT sits at the token layer. It is a compact, signed format for carrying claims such as issuer, subject, audience, expiration, and scope-related metadata.

A practical architecture often looks like this: OAuth performs the authorization dance, and the resulting access token may be a JWT. But that is an implementation choice, not a requirement. Some OAuth tokens are opaque and must be introspected; some JWTs are used outside OAuth altogether for authentication or service-to-service assertions. Teams should validate the token type, audience, issuer, and expiry separately from the business permission being requested.

  • Use OAuth when you need delegated access, consent, and scoped API permissions.
  • Use JWT when you need a signed claim container that can be verified by receivers.
  • Do not rely on the presence of a JWT to imply authorization.
  • Do not assume OAuth scopes alone are enough if the token audience or issuer is wrong.

For control guidance, NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams tie token handling to access enforcement and logging expectations, while NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is useful for understanding why service accounts, api key, and delegated tokens need distinct governance. These controls tend to break down when microservices, SaaS connectors, and third-party integrations all share the same token validation path because audience and scope checks become inconsistent.

Common Variations and Edge Cases

Tighter token controls often increase integration overhead, requiring organisations to balance developer convenience against stronger trust boundaries. That tradeoff becomes sharper in distributed systems, where teams may prefer JWTs for stateless validation but still need OAuth to manage consent and delegated permission.

There is no universal standard for every API pattern. Some systems use OAuth purely for user delegation, then issue short-lived JWT access tokens. Others use JWT-based service assertions inside a broader Zero Trust design. Best practice is evolving around short token lifetimes, explicit audience restriction, and clear separation between authentication, authorization, and token format.

Edge cases matter. A JWT can be self-contained yet still unsafe if signing keys are poorly rotated or if claims are trusted without validation. OAuth can also be misapplied when scopes are too broad, refresh tokens are overexposed, or third-party apps retain access long after they should have been revoked. The lessons from the Microsoft OAuth Breach and CoPhish OAuth Token Theft via Copilot Studio are straightforward: delegation without tight scope, expiry, and revocation becomes a standing access problem. The most common failure point is when teams trust the token format more than the authorization decision behind it.

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, OWASP Agentic AI Top 10 and CSA MAESTRO 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-1 OAuth and JWT both affect identity and access enforcement.
NIST SP 800-63 AAL2 Token trust depends on identity assurance and session handling.
OWASP Non-Human Identity Top 10 NHI-03 OAuth tokens and API credentials are core non-human identity assets.
OWASP Agentic AI Top 10 OAT-04 Agentic and API-driven systems rely on runtime token validation.
CSA MAESTRO IAM-02 Delegated access and token usage must be governed in distributed systems.

Require appropriate assurance and token lifecycle controls for delegated access.