Search for a command to run...
Experienced Business Analyst with a demonstrated history of working in the airlines/aviation industry. Strong research professional with a engineer focused and a strong technical background. Skilled in SQL/PLSQL, Linux System Administration. A proud Oracle APEX Consultant.
No comments yet. Be the first to comment.
Audit Information The Audit section captures key metadata about each component in your APEX application. Specifically, it records: Changed By: The username of the last developer who modified the component. Changed On: The timestamp of the last modi...
In this fifth post of The Standard Component Attributes Anatomy series, I’m focusing on the Configuration attribute—better known as Build Options. Since Build Options are managed in Shared Components, we’ll take a quick look at that area as well. Con...
Comments The Comment attribute might be one of the most universally available fields in Oracle APEX. It allows developers to quickly leave notes or remarks—for themselves or for teammates—that are never shown to end users during runtime. You'll find ...
In this fourth post of The Standard Component Attributes Anatomy Series, we’re diving deep into the Help standard attribute. Although often overlooked, the Help attribute plays an important role in improving the user experience by providing clear, co...
In this third post of The Standard Component Attributes Anatomy Series, I’m tackling the Security attribute. Since the Security section includes references to Authorization Schemes from Shared Components, we’ll briefly touch on that as well. And beca...
When working with publicly exposed applications, security should always be a top priority for developers. The more security responsibilities you can delegate, the better. One of the key aspects to delegate is authentication.
In this post, I will explore the integration of multiple public authentication providers, which can add flexibility to your application. This allows users to log in using their Google or Microsoft accounts, depending on their preference or existing credentials.
Delegating the authentication process means you won't need to save or handle any user credentials. There's no need for registration or password reset flows—all of this comes out of the box in Oracle APEX using the industry-standard OAuth 2.0.
A few things to consider:
You’ll need to implement various identity providers to accommodate the majority of your potential users (not covered in this post).
A landing page will be required for users to choose which provider to use.
Ensure the "Switch in Session" option is enabled for all authentication schemas.
As you might already know, Oracle APEX provides a native and declarative way to integrate with any identity provider that follows the OAuth 2.0 standard. I won’t go into detail on how to set this up, as there's plenty of documentation available on the topic. The process is quite similar for each provider:
Register with the provider’s development portal.
Create an API key to consume services using your APEX callback URL.
Add the credentials to your workspace credentials.
Configure the authentication schemas in your application.
Make sure the scheme name is simple to avoid complications later on. For example, use GOOGLE for Google or AZURE for Microsoft, rather than something longer like 'Google Identity Provider.
Optionally, if you have multiple applications in the same workspace, you might consider creating a master application to manage authentication—either by sharing the authentication cookie or by subscribing to the schemas in other apps.
By default, one of the configured authentication schemes will be active. When you run your application, users may unexpectedly land on the identity provider’s login page, which can be confusing. For example, they might request access to your application and be redirected to the Google or Microsoft login page without prior notice.
We’ll address this issue in the next section, but first, ensure that the 'Switch in Session' attribute is enabled for all your configured authentication schemes. You can find this option in the Login Processing section of your authentication scheme settings.
This option is critical in the process because, if enabled, it allows the current session's authentication scheme to be changed by passing APEX_AUTHENTICATION=scheme_name in a URL's request parameter. I will explain how this works in the next section.
The first important aspect to consider is the user authentication flow. The logical approach is to present a decision page where users can choose which provider to use. With a button click, users should communicate their choice to APEX.
For my Climbing Club application, I used the following approach:
Create a New Public Page: Design a new page with all the information you need for user decisions.
Set the New Decision Page as the Home Page: Go to Shared Components > User Interfaces > Attributes > Home URL and set your new decision page as the home page of your application.
Create a Before Header Branch to redirect users to the Authenticated home page of your application. Under Security, set the Authorization Scheme to Must Not Be Public User. This ensures that users are directed to the page you want them to visit once authenticated, rather than remaining on the decision landing page.
On the landing page, create a button for each authentication scheme.
Set the button action to Redirect to Page in this Application.
Again, for the target page, select the page you want users to visit once they are authenticated.
In the 'Request' section, set the Special Request in the format APEX_AUTHENTICATION=<Authentication Scheme Name> as mentioned in the previous section.
With these simple steps, your authentication flow should be clearer for users and flexible enough to allow them to select the identity provider that best fits their needs.
Enjoy Life!