Oracle APEX - Debugging a Social Login

Debug led light on brick w
Oracle APEX - Debugging a Social Login

Integrating social login within Oracle APEX offers remarkable convenience. I've had the privilege of configuring various Identity Providers (IdP), such as Azure AD, Google, Oracle IDCS, PING, and more. Generally, the setup process is quite smooth, and authentication functions seamlessly. However, the real challenge arises when things don't go as expected.

For those seeking assistance with the initial setup, we recommend referring to our previous blog post, which covers the fundamental configuration steps. You can find it here.

In this blog post, we'll explore how to fix issues with social login in Oracle APEX. We'll uncover the hidden challenges that can make this seemingly easy process a bit tricky.

Debugging Authentication in APEX

Debugging in APEX is typically a straightforward process for developers. When you're running a page in an application and logged in as a developer, you can easily activate the debug mode through the developer toolbar, and you're all set to start debugging.

Screenshot of Oracle APEX developer toolbar, debug menu
Oracle APEX - Debug in developer toolbar when logged in Application builder as a developer

Once the desired debug level has been activated, you can inspect the debug trace by refreshing the page and selecting the "View debug" option within the same menu.

The problem with our scenario is that to switch on the debug mode from the developer toolbar we already need to be sat on a page in the application and by that point the process of authentication has already happened.

Assuming that your initial redirect to the IdP proceeds without any issues, we'll need to take a slightly different approach to debug the second part of the authentication process.

To begin, initiate the process by running the APEX application, but refrain from signing in through just yet. As an example, the screenshot below illustrates a typical Google authentication screen that appears after being redirected by the APEX application using Google as an IdP.

Screenshot of Google Sign In screen
Oracle APEX - Login Screen after initial APEX redirect
Please note that in some cases, if your Single Sign-On (SSO) session is still active, you will be automatically redirected to APEX, making it impossible to perform debugging. To ensure a successful debugging session, make sure you are logged out before attempting any troubleshooting.

Here's the crucial point to understand: An APEX session has already been generated in the system for an anonymous user before being redirected to the Identity provider. What makes sense at this point is to enable the debug mode behind the scenes, ensuring that the next interaction with APEX will be subject to debugging.

To enable that, we are gonna use the Monitor Activity that is available in Application Builder. You can found it under the administration button in the top right hand corner of Application Builder.

screenshot of Oracle APEX Application Builder, Administration menu on the top right corner to access monitor activity.
Oracle APEX - Administration Menu > Monitor Activity

Once there, navigate to the Active Session page:

screenshot of Oracle APEX Application Builder Monitor Activity
Oracle APEX - Monitor Activity page

Here you need to find the latest active session with the username "nobody". This will be be the session that APEX has created and is presently using in the redirect to Google.

screenshot of Oracle APEX Application Builder Monitor Activity Active Sessions
Oracle APEX - Active Sessions Report

Click on that session and in the following window make sure that debug level session is set to "APEX Trace" and hit apply.

Screenshot of popup menu for debug level.
Oracle APEX - APEX Trace debug (Level 9)

Now, return to your Google (or whichever Identity Provider you are using) confirmation window and proceed with the login. The authentication process might then grant you access to the APEX application.

Finally, go back to the APEX developer environment, refresh the session window, and you should observe something similar to the following.

All the information you need for debugging the authentication process will be located under the debug ID labelled as the authentication callback "Page view type."

Please note that there are various levels of debugging, ranging from 1 to 9. The higher the number, the more extensive the log. The "Trace" level, which is the highest, is the only debug level that will capture the actual JSON response from the User info call.

This enables you to examine every step of the process with the highest level of debugging, providing an extensive wealth of information about the inner workings of the OAuth2 process, including the detailed exchange of data and tokens.

Checking User Info

In addition to user identification, an Identity Provider can furnish valuable insights about the user accessing a system. This information can be leveraged to influence the behaviour of our application. For example, a common scenario involves requesting the user's group affiliations and utilising them for authorisation within Oracle APEX.

To find out if the needed information is returned by the User Info call, Look for a record mention the payload response following this line:

sreenshot of debug trace in Oracle APEX
User Info call to Google IdP in Oracle APEX

The interesting part is the final JSON payload delivered to APEX by the Identity Provider, which should resemble this:

  "birthdate": "",
  "email": "[email protected]",
  "email_verified": true,
  "family_name": "Collins",
  "gender": "",
  "given_name": "Simon",
  "groups": [
      "id": "c449293933044ec7acb5c0f38a583",
      "name": "apx-admin",
      "$ref": "http://in-admin:9246/admin/v1/Groups/c449293933044ec7acb5c0f38a583"
      "id": "a153bf1433054fd2bebfeaba90c71",
      "name": "apx-modify",
      "$ref": "http://in-admin:9246/admin/v1/Groups/a153bf1433054fd2bebfeaba90c71"
  "name": "Simon Collins",
  "preferred_username": "simonc",
  "sub": "simonc",
  "updated_at": 1697469379,
  "website": ""

We can see that IDCS has provided, along with my name, email and username, an array of groups that I am part of (in this case the names are apx-admin and apx-modify).

If any property is missing in the response, it could be due to the scope requested from the IdP not being as expected or in a wrong format.


Debugging a Social Login authentication method in APEX is technically straightforward, but it can become challenging due to the varying attributes and information returned by different Identity Providers.

Happy debugging!

Find out more about our APEX services