Context

APEX Custom Authentication is a component of APEX applications that activates when a user signs in. It allows you to create a user validation/authentication function using PL/SQL logic, returning TRUE if the user is authenticated and FALSE if not. The validation process can use credentials maintained by the application or external services like Facebook, Google, or Active Directory. APEX Custom Authentication serves as an alternative to Oracle’s built-in authentication services.

It's important to distinguish between authentication and authorization. Authentication confirms a person's identity and matches it with the authoritative source for validation. Authorization determines what rights, privileges, and roles they have, if any. The Authentication Component focuses only on authentication, which is also the focus of this post.

Objective

Identify key factors to consider when developing an APEX Custom Authentication function.

Key Factors

• Validations to consider:

  • Is the system available for login? Is it in maintenance mode? Are there geographic or device restrictions?

  • Are the User ID and Password provided?

  • Are the User ID and Password valid?

  • Are the User ID and Password valid for the system they are logging into, especially in multi-tenant applications?

  • Is the password a default or expired one, requiring a mandatory change?

  • Has the User ID and Password been exposed in a breach, and is the password strong enough? Should a password change to a stronger one be enforced? The Have I Been Pwned site offers excellent APIs to check how often a password appears in breach databases without sharing the entire password with the API. (Have I Been Pwned: Check if your email address has been exposed in a data breach) Details on setting it up here: Easily and securely check user passwords for compromise

  • Is the user account expired, or is their login disabled?

  • Has the user exceeded the failed login attempts? Is there a timer for account restoration?

• Logging and Event Management

  • Logging for all attempts and the results, i.e. success, failure, referral to further action such as password reset.

  • Log attributes

    • User ID

    • IP Address

    • Device / Browser

    • Date and time

    • Procedure/function requesting the log entry

    • Error or success description

    • Service that was access was attempted to (especially multi-tenant)

• Actions

  • Metadata entries describe which attempts generate alerts, the type of alerts, who receives them, and whether notifications are delayed or immediate.

  • What events lead to changes in user or system privileges? What is the threshold for repeated login failures that cause account lockout or system lockout?

  • What actions trigger a forced password reset and re-verification of User ID and identity, or require a call to the user support center?

    💡

    Defining these constraints and action responses in metadata tables, which can be modified through a user interface by authorized users, simplifies maintenance and documentation.

• Functionality

  • Self-Service: Are there self-service options to save time for both customers and customer service?

    • User Registration: Is there a self-service process for new users to authenticate themselves and set up their User ID and password?

    • Password reset/change

    • Forgot password

    • Re-validation requiring more thorough verification if there are too many failed login attempts

  • Alternate login method if an external authentication service is unavailable? For example, what if Active Directory is temporarily down? (There might not be much you can do here, but having a contingency plan is important).

  • Two-factor authentication:

    • Offer two-factor authentication options, preferably including an authenticator app and/or hardware key options. The ease with which hackers can clone phone numbers has made texting codes less secure. Typically, user IDs match email addresses. If the email account is hacked, emailing the two-factor code is useless. At a minimum, two-factor authentication should be required. The approach will vary depending on the organization's and system’s risk profile.

    • Transmission of the two-factor codes should come from the database, not the browser. The browser should not "see" the code. The code should be sent to the user, who then types it in. The browser "asks" the database if it matches, without ever knowing what was sent, so it cannot be captured in the browser by the user.

    • When relying on social media or external accounts for authentication consider whether those accounts force two factor authentication as a rule. Otherwise, you cannot be sure that the user enabled two factor authentication, in which case the ability to rely on the social media or external service is diminished.

• Security

  • Logs, Events, and Alerts: What is the strategy for regular monitoring of login attempts and results? The review and response, frequency, alert levels, and messaging will vary depending on the system and users. However, a clear strategy should be in place for actively monitoring the system.

  • Code Review: Conduct periodic code reviews of the Authentication Custom Component and related policies/procedures.

    • Does it still align with current policies and procedures?

    • Do the metadata constraint settings need changes?

    • Are there sections that are no longer used or applicable? Was there a system migration that left some options unused?

    • Performance improvements?

  • Testing

    • Is it still working as it should?

  • Passwords should be hashed and not stored in the clear.

  • End to end encryption and security certificates should go without saying…

Conclusion

We have described Oracle APEX Custom Authentication and discussed important factors to consider when creating, implementing, and managing the module in operations. We hope you find this discussion helpful in your own work. If you do, please like this article.