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.
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.
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:
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.
In this setup:
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.
Fig. 2- True OAuth 2 Flow with External Authorization Server and Apache OFBiz as Resource Server
When evaluated against these requirements, Apache OFBiz’s earlier API security model met some, but not all of them:
|
OAuth 2 Resource Server Requirement |
Apache OFBiz (Before change in JWT validation logic) |
|
Bearer tokens |
✅ |
|
JWT format |
✅ |
|
Stateless REST APIs |
✅ |
|
External token issuer support |
❌ |
|
JWKS / public key verification |
❌ |
|
Issuer (iss) validation |
❌ |
|
Audience (aud) validation |
❌ |
|
External systems can obtain access tokens without storing Apache OFBiz user credentials |
❌ |
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.
OAuth 2 deliberately separates responsibilities across different components:
This separation is fundamental. A system does not become OAuth 2 compliant by issuing tokens, it becomes compliant by playing its role correctly.
In a clean OAuth 2 architecture, a Resource Server:
Crucially, a Resource Server does not authenticate users directly and does not manage passwords.
Just as important is what a Resource Server should not do:
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.
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:
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.
Before changes, validateToken() assumed a single trust model:
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:
This allows Apache OFBiz to evolve without forcing a breaking change.
1. Local Issuer Token Mode (OFBiz-Issued Tokens)
In this mode:
This remains useful for:
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:
Verification is done using:
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.
When verifier.verify(jwtToken) is executed, Apache OFBiz performs three essential checks:
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.
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.