Custom Database Connection Security Best Practices
Access legacy identity storage via custom API
We recommend that you implement an API to provide least privilege to your legacy identity storage rather than simply opening up general access via the internet.
Protecting legacy identity storage from general access is a recommended best practice. Exposing a (legacy identity) database directly to the internet, for example, can be extremely problematic: database interfaces for SQL and the like are extremely open in terms of functionality, which violates the principle of least privilege when it comes to security.
The alternative is to create a simple (custom) API—protected via use of an access token—that each action script can call. This would act as the interface to the legacy identity store. Client credentials grant flow can then be used to obtain an access token from within a script, and this can be subsequently cached for re-use within the global
object to improve performance. The API can then provide a discrete number of protected endpoints that perform only the legacy (identity) management functionality required (e.g., read user, change password).
By default, Auth0 will give you a token for any API if you authenticate successfully and include the appropriate audience. Restricting access to the legacy identity store API by restricting access token allocation via the use of a rule will prevent unauthorized usage and will mitigate a number of attack vector scenarios, such as where redirect to /authorize
is intercepted and the audience to the API is added.
Access to legacy identity storage
Whether managing access to legacy identity storage via custom API or using the native interface provided, you should restrict access to the list of IP addresses associated with your Auth0 tenant. To see the list of IP addresses, read Auth0 IP Addresses for AllowLists. Adding URLs to the AllowList constrains access to the legacy identity store and ensures that only custom database actions scripts defined in Auth0 are permitted.