All posts · General

OAuth 2.0 and JWT in Oracle Cloud: A Developer Guide

How OAuth 2.0 authentication and JWT tokens work in Oracle Cloud — understanding the flows that OIC, VBCS, and Fusion REST APIs rely on.

Anurag Jangra · March 8, 2026 · 6 min read · ... views

Why OAuth matters for Oracle Cloud developers

Every OIC integration that calls a Fusion REST API uses OAuth 2.0. Every VBCS application session is backed by an OAuth token. Understanding how this works — not just how to configure it — helps you diagnose authentication failures and design secure integrations.

OAuth 2.0 core concept

OAuth 2.0 is an authorisation framework. It allows a client application (OIC integration, VBCS app) to obtain permission to access resources (Fusion API, ATP database) on behalf of a resource owner (a user or a service account) without exposing credentials.

The key insight: the client never sees the user’s password. It receives a time-limited access token from the authorisation server (IDCS), which it presents to the resource server (Fusion API).

Grant types used in Oracle Cloud

Client Credentials: machine-to-machine authentication. OIC integration → Fusion API. No human involved.

POST /oauth2/v1/token
grant_type=client_credentials
client_id=your-client-id
client_secret=your-client-secret
scope=urn:opc:resource:consumer::all

Response: {"access_token": "eyJ...", "token_type": "Bearer", "expires_in": 3600}

Authorization Code: human-facing authentication. User → VBCS app → IDCS login page → token issued. Used for VBCS applications where users log in via a browser.

JWT Assertion: service-to-service where one service presents a signed JWT instead of a client secret. More secure for high-security integrations.

JWT structure

JSON Web Tokens (JWT) are Base64-encoded tokens with three parts: Header.Payload.Signature

The payload contains claims:

{
  "iss": "https://idcs.oracle.com",
  "sub": "service_account@company.com",
  "aud": "https://fusion.fa.em2.oraclecloud.com",
  "exp": 1751820000,
  "iat": 1751816400,
  "scope": "urn:opc:resource:consumer::all"
}

Key claims: sub (who the token is for), exp (expiry timestamp), scope (what permissions the token grants).

Debugging OAuth in OIC

When OIC returns 401: check if the token has expired (OIC caches tokens — a restart may be needed). Check if the IDCS application has the correct scope assigned. Verify the token URL is correct — IDCS domain URL vs OCI IAM domain URL differ in format.

Use jwt.io to decode the access token and inspect claims — it reveals exactly what permissions the token carries and when it expires.

Token expiry and refresh

OIC handles token refresh automatically for most adapter types. For custom REST connections using OAuth, configure the refresh strategy in the connection settings. For VBCS, the session management handles refresh via IDCS seamlessly.

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp