We can set up SSO for an Oracle APEX application on Autonomous Database, using Oracle Identity Cloud Service (IDCS) as the identity provider via OAuth2 / OpenID Connect. Here’s the full walkthrough.
What we’re building
- Authentication: an OAuth2 / OpenID Connect “Social Sign-In” scheme in APEX, backed by IDCS as the identity provider
- Authorization: an IDCS group controlling who can access the app
- Logout: proper single logout (SLO) so ending the APEX session also ends the IDCS session
Part 1: Registering the application in IDCS
1.1 Creating a Confidential Application
First, we head into the IDCS admin console: Domains → Default → Integrated applications → Add application.
We need to choose Confidential Application here — this is the right type for a server-side app like APEX that can protect a client secret.
1.2 Basic details
We give it a name (APEX_OAUTH_SSO_APP) and leave the Application URL blank for now.
We leave “listed on My Apps page” and “user can request access” off, since we’re not using those. We do turn on “Enforce grants as authorization” — this means only users/groups we explicitly grant access to the app can use it.
1.3 Resource server vs client configuration
Since our APEX app isn’t exposing its own protected API to other clients, we choose No resource server configuration, and under Client configuration we choose Configure this application as a client now.
Under Allowed grant types, we check Authorization code only — the standard OAuth2 flow for a server-side web app like APEX.
1.4 Redirect URL, post-logout redirect URL, and logout URL
This is the part that’s easy to get wrong. Three separate URL fields matter here:
- Redirect URL — where IDCS sends us back after login. For APEX this is the built-in callback endpoint: https://<your-apex-host>/ords/apex_authentication.callback.
- Post-logout redirect URL — where IDCS sends us after it finishes logging us out. We pointed ours at IDCS’s own end_session_endpoint as a placeholder here, and set the real destination in the APEX authentication scheme’s “Post-Logout URL” field (Part 2.4).
- Logout URL — IDCS’s own logout endpoint, used to identify this as a valid front-channel logout target.
1.5 Client type and token settings
We set Client type to Confidential (not Trusted — Trusted is for self-signed assertions, which we’re not using).
We leave Bypass consent off (more on this in the Gotchas section below) and leave Authorized resources as All.
We submit, and the app is created in an Inactive state — we activate it from the Actions menu.
1.6 Creating a group and assigning users
Rather than granting access to individual users, we create a group and assign users to it — this makes access management much easier down the line.
We go to Domains → Default → Groups → Create group.
We give it a name, APEX_OAUTH_SSO_GROUP.
We open the group, go to the Users tab, and click Assign user to group.
We select the user(s) who should have access.
They now show up under the group’s Users tab.
1.7 Assigning the group to the application
Back on the application, we go to the Groups tab and click Assign groups.
We select the group we just created.
The group now appears under the app’s Groups tab — only members of this group can sign in to our APEX app via this IDCS application.
Part 2: Configuring APEX to use IDCS for authentication
2.1 Creating Web Credentials to store the Client ID/Secret
In APEX, we go to our workspace home → Workspace Utilities.
We choose Web Credentials.
We click Create.
We fill in: - Name: something descriptive, IDCS Web Credentials - Authentication Type: OAuth2 Client Credentials - Client ID or Username: the Client ID from our IDCS application (found on the app’s OAuth configuration tab)
We fill in the Client Secret (from IDCS) and confirm it, then click Apply Changes.
We now see it listed under Web Credentials.
2.2 Opening our application and going to Shared Components
Back on the workspace home, we open our target application.
From the application home, we click Shared Components.
Under Security, we click Authentication Schemes.
We click Create.
2.3 Creating the Social Sign-In authentication scheme
We set: - Name: IDCS SSO - Scheme Type: Social Sign-In - Credential Store: the Web Credentials entry we created in 2.1 - Authentication Provider: Generic OAuth2 Provider - Authorization Endpoint URL: https://<your-idcs-instance>.identity.oraclecloud.com:443/oauth2/v1/authorize - Token Endpoint URL: https://<your-idcs-instance>.identity.oraclecloud.com:443/oauth2/v1/token
Continuing down the Settings section: we leave User Info Endpoint URL blank (not required for this flow), set Scope to openid profile email, and set the Username field — this determines what claim from the ID token becomes the APEX username.
On the Username field: APEX’s default template here is #sub# (#APEX_AUTH_NAME#), which produces a username string like <sub-value> (John Doe) — not what we wanted for display purposes or downstream matching against APEX user accounts. We changed ours to just #sub# (see Part 2.6 below) once we noticed this showing up oddly in the app.
2.4 Login Processing and Post-Logout URL
Under Login Processing, we can optionally set Pre/Post-Authentication procedures if we need custom logic (e.g. auto-provisioning a database user). We left these blank for a simple setup.
Under Post-Logout URL, we set Go To: URL and point it at IDCS’s end-session endpoint: https://<your-idcs-instance>.identity.oraclecloud.com/oauth2/v1/userlogout
This is what makes logout actually terminate the IDCS session too, instead of just the local APEX session.
2.5 Finding our endpoints from the IDCS discovery document
When we weren’t sure of the exact endpoint URLs, we fetched our IDCS discovery document:
https://<your-idcs-instance>.identity.oraclecloud.com/.well-known/openid-configuration
This returns all the endpoints we need (authorization_endpoint, token_endpoint, end_session_endpoint, etc.) in one place.
2.6 Making it the current scheme
Once saved, we click Make Current Scheme to activate it for the application.
We see it marked Yes under “Is Current” in the Authentication Schemes list.
2.7 Testing it
We go back to the application home and click Run Application.
This redirects us to the IDCS sign-in page.
After authenticating, we land back in the APEX app, authenticated as the IDCS user.
2.8 Cleaning up the username claim
Going back into the authentication scheme’s Settings, we revisit the Username field — still showing the default #sub# (#APEX_AUTH_NAME#) template.
We simplify it to just #sub# so the APEX username is a clean identifier without the parenthetical display name tacked on, then click Apply Changes.
