Introduction
If you, like me, have wondered why you would ever use Open Door Credentials, then this post is for you.
Open Door Credentials are a powerful tool when used for the right reasons and in the correct instance. They make testing and troubleshooting easier, especially for applications using Authentication Schemes like Social Sign-On, but they require discipline and restraint.
⚠
Open Door Credentials should only be used as a temporary tool for testing and troubleshooting. Once you have completed your testing, they should be removed and should never (ever) be deployed to production.
What are Open Door Credentials?
Open Door Credentials allow you to sign on to an APEX application using a username and a password. Nothing unusual there. The difference is that you can sign in using any username and password, even if they do not exist in your application. You can enter Username: ABC and Password: XYZ, and APEX will still let you in. This applies only to Authentication. Authorization, application logic, and security checks still apply and should be used to control what the authenticated user can actually do.
😱
Although this sounds super scary, it does have its uses in certain limited situations.
Once the user is signed in with Open Door Credentials, as far as your APEX App is concerned, there is nothing different:
Once authenticated, the username behaves like any other value in :APP_USER. This means all authorization schemes, row-level security logic, VPD policies, and application-specific checks will execute exactly as they would for a real user, assuming you validate the username correctly.
Any code you have in the Login Processing section of the Authentication Scheme (Pre-Authentication Procedure Name, Post-Authentication Procedure Name) is still executed.
Why are Open Door Credentials Useful?
Open Door Credentials are particularly useful during the testing phase of a project and for troubleshooting issues. They allow you to experience exactly what that user is experiencing.
💡
I find Open Door Credentials most helpful for Applications that rely on Social Sign-on (e.g., Okta, Active Directory, Google) for authentication because these apps do not have a login page, and you cannot spoof other users.
An example of where Open Door Credentials are useful is when testing APEX Workflow. With APEX Workflow, you often need to log in as multiple users to test the process end-to-end. Getting all the participants on a call to test is impractical, and having their passwords is insecure. Open Door Credentials allow you to test the end-to-end process yourself.
Words of Caution
It may seem obvious, but I will say it anyway. Never use Open Door Credentials in Production.
Open Door Credentials should not be used (even in DEV) for applications that store personally identifiable information or any other data that requires security. That is, unless you mask this data when you clone from PROD to DEV/TEST.
If your DEV APEX App is open to the internet, then you should either add an IP restriction to your load balancer or restrict access to the APEX App you are testing by IP Address while testing with Open Door Credentials.
Validate the username. Open Door credentials will accept any username and password. You should validate that the username is a valid user of your application in the Application Level Authorization Scheme (hopefully, you were already doing this).
How to Create Open Door Credentials
Navigate to Shared Components > Authentication Schemes
Click Create and select ‘Based on a pre-configured scheme from the gallery’.
Select ‘Scheme Type’ as ‘Open Door Credentials’, and click ‘Create Authentication Scheme’.
Add your usual Pre and Post-Authentication logic:
Logging In
When you make the new Authentication Scheme, the current scheme and login, you will be presented with an APEX-generated login page like this:
Note: When using Open Door Credentials, the password value is ignored by the Authentication Scheme. Any password will be accepted.
Interestingly, some environments, e.g., https://oracleapex.com/, only show the username:
Deploying the App from DEV to PROD
Unfortunately, Authentication Schemes do not currently have Build Options. With a build option, you could set it so that APEX automatically excludes the Authentication Scheme whenever you export it for deployment to another instance.
Not having Build Options means you must manually delete the Open Door Credential Authentication Scheme before you deploy to PROD. There is an idea in the APEX Ideas App to add Build Options to Authentication Schemes. Even though it is flagged as on the Roadmap, it is over 4 years old, so I encourage you to vote for it.
Alternatives to Open Door Credentials
Another option is to use the Oracle APEX Accounts Authentication Scheme and create dedicated test users. This approach uses real credentials, but it requires you to build a login page and ongoing user management, which may be impractical for short-lived testing scenarios.
Conclusion
Open Door Credentials are a powerful tool when used for the right reasons. They make testing and troubleshooting simpler, especially for applications using external authentication, but they require discipline and restraint. Use them responsibly, lock them down properly, and remove them before deploying to production.
