How to Embed a Custom App Inside Oracle Fusion Cloud (Without Breaking Security)

Most teams that need something Oracle Fusion Cloud doesn't do out of the box end up with a *parallel* system — a separate web app, with its own login, its own user list, and its own audit trail to govern. It works, but now your security team has two worlds to reason about instead of one.

There's a better pattern: build the app so it lives inside Fusion and inherits the security you already have. Here's how it works.

The mechanism: Page Integration

Oracle Fusion's Page Integration Framework lets you surface an external application inside a Fusion page — as a Secure Destination — so the user never leaves their ERP. From the user's perspective it's just another Fusion screen. From an architecture perspective, three things matter:

**JWT SSO.** Fusion mints a signed JSON Web Token for the logged-in user and passes it to your app. Your app validates the token against Oracle's certificate. No second password, no separate identity store.

**Inherited roles and data-access.** Because the identity comes from Oracle, your app can resolve the user's Oracle roles, business units, and data access sets — and enforce exactly the same boundaries the rest of Fusion does.

**One audit perimeter.** Access is granted and revoked in Oracle. There is no parallel entitlement system for an auditor to reconcile.

That last point is the whole game. Segregation of duties and access governance stay where your controls already live.

What you can build this way

Anything that needs a richer interface or logic than a standard Fusion page allows, but must respect Oracle's security:

Finance dashboards reading live GL data

Project cost-control and PPM screens tied to live PA data

Approval and exception-handling workflows

Supplier and customer self-service portals

Bulk data-entry grids (this is where a real enterprise data grid earns its keep)

The parts that bite people

A few hard-won notes from doing this in production:

**Validate the JWT properly** — check the signature, issuer, audience, and expiry. A token you don't verify is worse than no token.

**Resolve data-access, not just roles.** A user's *role* tells you what they can do; their *data access set* tells you which business units and ledgers they can see. Enforce both, or you've quietly created a data-leak.

**Track Oracle's quarterly updates.** Page Integration is a supported mechanism, but you should regression-test your embedded app against each Fusion release rather than discover a change in production.

Why not just use VBCS?

Oracle's own answer to "I need a custom screen" is Visual Builder. It's supported and it's fine for simple forms — but for anything with real interactivity, enterprise data grids, or AI features, modern web frameworks give you far more control and a better developer experience. We've [written separately about that trade-off](/blog/why-nextjs-over-vbcs-for-oracle-erp). The embedding pattern above works regardless of which framework you choose.

The bottom line

If you build *beside* Oracle, you inherit a second system to secure and audit forever. If you build *inside* it — Page Integration, JWT SSO, inherited roles — security and governance stay in Oracle, and users get a modern experience without a context switch.

That's the model we use for every embedded app we ship. If you've got an Oracle workflow that needs a better interface, [tell us the one that hurts most](/scope) and we'll stand up a working prototype on your own Oracle test instance in two weeks.