When you create an APEX application using the blueprints, you have no option to opt-out of creating an Authentication Scheme and a Login Page.
APEX wants to create a highly secure application. It will create an additional bunch of security features as you simply click through the steps.
Once the application is created, you may change your Application’s Authentication to use an alternative scheme or to use a set of switch-in-session schemes. For example, an Application may have more than one Authentication Scheme to offer alternatives for the user. The screenshot below demonstrates three options.
I will now discuss the APEX native Authentication options…
APEX supports native Social Sign-in with Google and Facebook. Other OpenID Connect and OAuth2 are supported too although require additional configuration.
OAuth2 configuration would extend access to other identity services such as Microsoft Azure, Office 365 and Oracle Cloud Identity Services.
There are prominent APEX community blogs explaining the steps involved in aligning your application with these identity services.
In the below picture I have a single page APEX application which demonstrates connectivity to Microsoft Azure.
If the user is already authenticated with Azure, the login page is bypassed and the user can access the APEX application homepage (above) directly.
If the user is not currently authenticated with Azure, the user will be presented with the Azure login screen. Upon successful authentication, the user will be redirected back to the APEX application home page.
As you can see from the picture – additional user information from Azure can be obtained and used within the APEX application.
This is usually a very convenient option for businesses. This allows the application to authenticate with a central LDAP server including Microsoft Active Directory.
The APEX Instance itself can be configured so that Workspaces can be authenticated against LDAP. This means that Developers use their LDAP credentials instead of having separate user accounts for each environment
APEX provides its own way of managing users, which are stored within the Application Express user repository. Following creation of an APEX application, this is normally the default option. Amongst numerous features, this also provides ability to lock, throttle and enforce password complexity.
This is a commonly used Authentication scheme as it offers a full, manageable authentication and user management system out of the box.
APEX allows the user to authenticate against DB users. This is best used in Oracle Forms to APEX projects where the existing Authentication can be continued without interruption. Note that Profile Options such as locking after unsuccessful login attempts are not observed, so alternative methods if achieving this are required to be built.
Custom is an Authentication Scheme that is regularly used. The advantage of this scheme is that the entire control is given to the developer. Using PL/SQL, the developer can create their own user tables and write their own code to validate user credentials and even incorporate 2 factor authentication solutions.
The disadvantages is that it moves away from the low-code principle and the developer has to write their own routines for password management and user locking after unsuccessful logins. These considerations are already achieved in other Authentication Schemes.
For some types of application, it is not appropriate to add an authentication scheme. This are typically read-only application with insensitive data.
A similar scheme, Open Door, exists which asks for a name the user wishes to known by – which may be applicable in some scenarios.
Single Sign-On can be achieved through a Kerberos implementation. This involves configuration of the web server and use of the HTTP Header Variable APEX Authentication.
SSO can be beneficial to the business as no APEX login page is displayed, ensuring that the authentication process is as seamless as possible.
This delegates authentication to the Oracle AS Single Sign-On (SSO) Server. To use this authentication scheme, your site must have been registered as a partner application with the SSO server.
Author: Matt Mulvaney
Job Title: Senior Oracle APEX Development Consultant
Bio: Matt is an experienced APEX solution designer having designed numerous complex systems using a broad range of Oracle Technologies. Building on his previous experience of Oracle Forms & PL/SQL, he is entirely focused on providing functionally rich APEX solutions. Matt promotes APEX as a software platform and openly shares best practises, techniques & approaches. Matt has a passion for excellence and enjoys producing high quality software solutions which provide a real business benefit.