Skip to content

Solution Patterns

Location: inception_core/accelerators/patterns_solution/

Solution patterns are enterprise-grade reference implementations covering identity propagation, secure token exchange, Oracle Fusion integration, browser-facing SSO login, and a reusable multi-tool chat agent architecture. Each pattern is a self-contained, runnable starting point — copy, extend, and adapt to your domain without rebuilding the foundation.

token_factory reference implementations

Five of these patterns form a matched set, each demonstrating one token_factory.TokenFactory target_tool end-to-end, from a browser login through to the downstream system. Start from whichever matches the target_tool you need — don't hand-roll a new token exchange.

Pattern Folder target_tool Downstream system
Service Token Acquisition service_get_token_oauth/ oauth Any Bearer-token-secured MCP server (headless CLI + NL2SQL chat app)
E2E Identity Propagation → ADB user_e2e_token_exchange_adb_dbtoken/ oracle-database Oracle Autonomous Database, VPD row-level security
E2E Identity Propagation → Object Storage user_e2e_token_exchange_os_oci-service/ oci-service OCI Object Storage
E2E Identity Propagation → OIC user_e2e_token_exchange_oic_oauth/ oauth Oracle Integration Cloud's native MCP server → EBS
User Impersonation → OIC (Basic Auth) user_impersonation_oic_basic_oauth/ userid OIC Basic Authentication trigger → EBS Adapter, using the caller's own EBS credential

All five share one IDCS confidential application and its registered redirect URI (http://localhost:8000/callback) — run one at a time locally, or register a second redirect URI to run more than one concurrently.

Other patterns

Pattern Folder Description
Async Fusion Agent Invocation async_invoke_fusion_agents/ CLI for Oracle Fusion AI Agent Orchestrator's /invokeAsync + /status polling. Not token_factory-based — a direct IDCS client-credentials grant.
IDCS Browser Login idcs_browser_login/ Zero-dependency Node package for a browser UI's IDCS OAuth2 Authorization Code flow — server-side session, HttpOnly cookie, and the platform's empty-groups-claim fix, consolidated out of four recipes that each independently hit it.
Reference Chatbot reference_chatbot/ Multi-tool LangGraph chat agent (KB search / NL2SQL / web search, pluggable short- and long-term memory) for any recipe that needs an open-ended, tool-using conversational entry point.
A2A Service Invocation a2a_invoke_services/ Stub — no implementation yet. Intended for agent-to-agent calls with OAuth credentials.

Choosing a target_tool

Need to call a native OCI SDK client (ObjectStorageClient, IdentityClient, ...)?
  → oci-service  (returns a TokenExchangeSigner)

Need a scoped Oracle Database token + session key for an externalauth connection?
  → oracle-database  (returns a DB token + private key)

Need a plain OAuth Bearer token for an HTTPS/REST call or another MCP server?
  → oauth  (returns {token, token_type, expires_in})

Just need to know who the caller is, without keeping a token?
  → userid  (returns {user_id})

oci-service and oauth both build a signed JWT assertion and exchange it with the Identity Domain — the difference is only in what comes back. Picking the wrong one for your downstream system is the most common integration mistake: an OIC REST call needs a Bearer token (oauth), not an OCI SDK signer (oci-service) — see E2E Identity Propagation → OIC for a concrete case where this distinction mattered.

Common setup

  • OCI tenancy with an Identity Domain (IDCS) configured
  • Python 3.11+, one virtual environment per pattern
  • Copy each pattern's sample.env to .env and fill in your values before running
  • Patterns that reach Oracle Autonomous Database need an Oracle Wallet — see Getting Started — Core Setup
  • Token Factory — the library every pattern here delegates its token exchange to
  • MCP Servers — the tool execution layer several of these patterns invoke
  • Architecture — how identity propagation fits in the platform stack