Transforming Apache OFBiz From OAuth-Like Token Authentication to a True OAuth 2 Resource Server

As enterprise systems become increasingly API-driven, a common question comes up during architecture and security reviews:

Can this system sit cleanly behind Okta, Microsoft Entra ID, or Keycloak?

For teams exposing Apache OFBiz through REST APIs, this question has historically been uncomfortable. Apache OFBiz has supported JWT-based authentication and Bearer tokens for its APIs, and for many internal integrations this worked well. But when evaluated against enterprise OAuth 2 expectations like external identity providers, delegated access, and zero passwords in tools, the implementation felt more OAuth-like than truly OAuth 2 compliant.

This distinction became clear during the development of the MCP (Model Context Protocol) server for Apache OFBiz. The MCP server is designed as a shared middleware, enabling Apache OFBiz to be integrated once and safely accessed by multiple LLM-based applications and AI agents without creating tight, point-to-point integrations. MCP brings modern OAuth requirements front and center: delegated authorization, strict audience validation, and seamless integration with enterprise IAM systems. To support this properly, Apache OFBiz needed to evolve from issuing and validating its own tokens to behaving like a true OAuth 2 Resource Server.

That evolution led to a key change in Apache OFBiz’s JWT validation logic, enabling Apache OFBiz to validate externally issued access tokens using standard OAuth 2 mechanisms. The result is a cleaner security model, better enterprise compatibility, and a foundation that supports modern use cases like AI agents, partner integrations, and zero-trust architectures. 

In this blog, we will walk through how REST API security in Apache OFBiz worked prior to this change, why that approach was best described as OAuth-like, and what specific enhancements were introduced to allow Apache OFBiz to behave as a true OAuth 2–compliant Resource Server. We will focus on the architectural expectations of OAuth 2, the role Apache OFBiz is meant to play in that architecture, and how recent changes align Apache OFBiz with enterprise Identity and Access Management (IAM) systems without disrupting existing integrations.

Implementation of MCP Server Exposed a Real OAuth Gap in Apache OFBiz

As enterprise systems evolve toward API-first architectures, the way they are consumed has changed dramatically. APIs are no longer accessed only by human users through web applications; they are increasingly consumed by mobile apps, partner systems, automation pipelines, and now AI agents.

This architectural shift immediately surfaces stronger security requirements. AI agents and automation tools cannot store backend passwords, cannot rely on shared secrets, and cannot be granted unrestricted access. Access must be delegated, scoped, and revocable, ideally through the same enterprise identity systems already used across the organization.

At this point, the distinction between JWT-based authentication and OAuth 2 compliance becomes critical. While Apache OFBiz already supported JWT Bearer tokens for REST APIs, MCP introduces a real trust boundary: identity and authorization are expected to be handled by an external Identity Provider, while Apache OFBiz is expected to focus purely on protecting its APIs.

In other words, MCP did not just introduce a new integration pattern, it forced Apache OFBiz to be evaluated through the lens of modern OAuth architecture. This is where the gap between an OAuth-like implementation and a true OAuth 2 Resource Server became both visible and unavoidable.

API Security in Apache OFBiz Before MCP Server

Fig. 1- Legacy OAuth Like Flow with Self Issued JWT Tokens

Before MCP entered the picture, Apache OFBiz already had a practical and functional API security model. APIs could be protected using JWT Bearer tokens, allowing clients to authenticate once and then make stateless API calls without relying on HTTP sessions.

A typical flow looked like this:

1. A client authenticated to Apache OFBiz using Basic Auth
2. Apache OFBiz issued a JWT token
3. The client called API services using:
   Authorization: Bearer <jwt>

This worked well for many real-world scenarios.

Example: Internal Mobile App

Consider a warehouse mobile app built and operated by the same organization running Apache OFBiz server. 

• The app authenticates using a technical OFBiz user
• It retrieves a JWT 
• It calls APIs like pickOrder, packOrder, or receiveInventory

In this setup:

• Apache OFBiz authenticates the user
• Apache OFBiz issues the token
• Apache OFBiz validates the token

The token is signed using a shared secret (HMAC method), and Apache OFBiz trusts it because it created it. For internal systems and controlled environments, this is simple, efficient, and perfectly reasonable.

What an OAuth 2–Compliant Resource Server Is Expected to Do?

Fig. 2- True OAuth 2 Flow with External Authorization Server and Apache OFBiz as Resource Server

1. Accept Bearer access tokens
2. Trust tokens issued by an external Authorization Server
3. Verify token signatures using public keys (JWKS)
4. Validate the token issuer (iss)
5. Validate the intended audience (aud)
6. Enforce token expiry and scope/claim restrictions
7. Rely on TLS (HTTPS) for all communication
8. Not request credentials from client applications

Where Apache OFBiz Fell into the “OAuth-Like” Category?

When evaluated against these requirements, Apache OFBiz’s earlier API security model met some, but not all of them:

So Apache OFBiz could only trust tokens that it issued itself. Because Apache OFBiz acted as both Authorization Server and Resource Server, trust was based on direct authentication with Apache OFBiz, and shared secrets.

Now consider integrating Apache OFBiz with a third-party system. Third Party System authenticates with an enterprise identity provider (IdP) such as Okta, Microsoft Entra ID, or Keycloak and receives an OAuth access token. It then attempts to call Apache OFBiz APIs using that token. Before the changes introduced as part of MCP integration, Apache OFBiz had no standard mechanism to verify the token’s signature using the IdP’s public keys, validate the issuer, confirm that the token was explicitly minted for Apache OFBiz, or safely accept externally issued tokens without relying on Apache OFBiz credentials. In practice, this left only the option of Apache OFBiz-issued tokens. From an enterprise security standpoint, this is precisely the problem OAuth 2.0 was designed to eliminate.

Though it’s important to be clear that this was not a bug or a poor design choice. Apache OFBiz is designed to be a powerful business platform, not an identity provider. For many years internal integrations dominated, APIs were consumed in trusted environments, shared trust models were acceptable.

Now the integration landscape changed with time. MCP, AI agents, partner systems, and zero-trust architectures introduced new expectations, i.e. making it necessary for Apache OFBiz to evolve from an OAuth-like model into a true OAuth 2 Resource Server.

What an OAuth 2 Resource Server Actually Is (and Is Not)?

OAuth 2 deliberately separates responsibilities across different components:

• Authorization Server
  Responsible for authenticating users and issuing access tokens
  (e.g. Okta, Microsoft Entra ID, Keycloak)
• Resource Server
  Responsible for protecting APIs and validating access tokens
  (e.g. Apache OFBiz REST APIs)

This separation is fundamental. A system does not become OAuth 2 compliant by issuing tokens, it becomes compliant by playing its role correctly.

What a Resource Server Is Responsible For?

In a clean OAuth 2 architecture, a Resource Server:

• Accepts Bearer access tokens on API requests
• Verifies token authenticity (signature validation)
• Ensures tokens come from a trusted issuer
• Ensures tokens were explicitly issued for itself (audience validation)
• Enforces expiry, scopes, and claims
• Treats tokens as opaque proof of authorization—not as login credentials

Crucially, a Resource Server does not authenticate users directly and does not manage passwords.

What a Resource Server Is Not Responsible For?

Just as important is what a Resource Server should not do:

• It should not issue OAuth access tokens
• It should not handle login flows
• It should not store user passwords
• It should not act as an Identity Provider

Those responsibilities belong to the Authorization Server.

This distinction matters because many systems including Apache OFBiz historically blur these roles for practical reasons, especially in internal deployments. 

Apache OFBiz takes the Resource Server Role

Before the change in Apache OFBiz’s JWT validation logic, Apache OFBiz could not cleanly sit behind an external Authorization Server. With the development of MCP Server for Apache OFBiz, external issuer validation was introduced that made Apache OFBiz take the role of  Resource Server. This is the architectural shift that turns Apache OFBiz from an OAuth-like system into a true OAuth 2 Resource Server. 

With this change in Apache OFBiz:

• Identity lives with IAM systems, such as Okta / Microsoft Entra ID / Keycloak / etc.
• Authorization decisions are expressed in tokens
• Apache OFBiz focuses purely on API protection and enforcement

What was actually changed in Apache OFBiz to support this role?

The answer lies in the evolution of the validateToken() method used to authenticate and authorize API requests. This method now supports two distinct validation paths, allowing Apache OFBiz to operate in both simple internal setups and enterprise OAuth environments, without breaking existing integrations.

From Single-Mode Validation to Dual Validation Models

Before changes, validateToken() assumed a single trust model:

• Apache OFBiz authenticated users
• Apache OFBiz issued JWTs
• Apache OFBiz validated JWTs using a shared secret

This worked as long as Apache OFBiz controlled both identity and token issuance.

To support MCP, and enterprise IAM systems, validateToken() was extended to dynamically choose how a token should be verified, based on configuration.

At a high level, the logic now looks like this:

• If an external issuer is configured → treat Apache OFBiz as an OAuth 2 Resource Server
• Otherwise → fall back to Apache OFBiz’s internal token validation

This allows Apache OFBiz to evolve without forcing a breaking change.

Two Validation Models in Practice

1. Local Issuer Token Mode (OFBiz-Issued Tokens)

In this mode:

• Tokens are issued by Apache OFBiz itself
• Tokens are signed using a shared secret (HMAC method)
• Apache OFBiz validates tokens using the same secret

This remains useful for:

• Development environments
• Demos
• Internal tools
• Simple integrations

Conceptually, Apache OFBiz is both issuer and verifier.

2. External Issuer Token Mode (OAuth 2 Resource Server)

This is the key addition.

In this mode:

• Tokens are issued by an external Authorization Server
  (Okta, Microsoft Entra ID, Keycloak, etc.)
• Apache OFBiz does not authenticate users
• Apache OFBiz does not issue tokens
• Apache OFBiz only verifies access tokens

Verification is done using:

• Public keys fetched from the issuer (JWKS)
• Issuer validation (iss)
• Audience validation (aud)

This is exactly how a standards-compliant OAuth 2 Resource Server behaves.

The Core Verification Step

At the heart of both models is a single, critical line:

DecodedJWT jwt = verifier.verify(jwtToken);

This line represents the security gate for every API call.

It is only executed after the verifier has been constructed with the correct trust rules either local or external.

What Happens During Token Verification

When verifier.verify(jwtToken) is executed, Apache OFBiz performs three essential checks:

1. Signature Verification
   • Ensures the token was issued by a trusted authority
   • Uses:
     • a shared secret (local mode), or
     • a public key from the issuer’s JWKS (external mode)
2. Issuer Validation (iss)
   • Confirms the token was issued by the configured Authorization Server
   • Prevents tokens from unknown or untrusted issuers
3. Audience Validation (aud)
   • Confirms the token was explicitly issued for OFBiz
   • Prevents token reuse across different systems

In practice, token expiry (exp) is also enforced as part of this verification.

Only if all checks succeed does Apache OFBiz trust the token and proceed to extract claims.

Conclusion

By evolving its JWT validation to support externally issued access tokens, Apache OFBiz now cleanly fulfills the role of an OAuth 2 Resource Server. This change allows Apache OFBiz to sit behind enterprise Identity and Access Management systems such as Okta, Microsoft Entra ID, and Keycloak, enabling centralized authentication. As account lifecycle management can be handled centrally, without duplicating identity logic inside Apache OFBiz, allowing organizations to manage access to Apache OFBiz using the same IAM policies they apply across the rest of their platform. This change also allows consistent access policies, and enterprise-grade security without relying on shared credentials or backend passwords.

External systems and partners can now access Apache OFBiz APIs using standard OAuth flows and scoped access tokens, with clear trust boundaries enforced through issuer and audience validation. This makes Apache OFBiz significantly easier to integrate into modern API-driven architectures while aligning it with the security expectations of enterprise platforms.

By aligning with standard OAuth 2 Resource Server behavior, Apache OFBiz now speaks the same security language as modern platforms and tools. This evolution was not about turning Apache OFBiz into an identity provider, but about clearly defining and implementing its role within a modern OAuth architecture. By doing so, Apache OFBiz strengthens its enterprise readiness and establishes a solid foundation for future integrations, while preserving the flexibility that has always been a core strength of the platform.