Security & Authentication Configuration

Authentication Settings (System-level)

Authentication Method
Used for all global pages and as default authentication for newly created projects
For details on each authentication method, see the REDCap Community website's authentication page, which describes them and lists how to install, configure, and enable each in REDCap.
Need help troubleshooting your LDAP configuration?

Two-Factor Authentication (recommended for improved security)

Enabling two-factor authentication (also known as 2-step login) can provide greater security with regard to users logging in to the system. While the standard login process consists of entering a username and password, two-factor authentication provides a second step after the initial login, such as entering a 6-digit verification code received via SMS text message, via email, or generated using the Google Authenticator app on their mobile device, or responding to a phone call or a push notification (for Duo app only). Two-factor authentication can be set up and enabled using the settings below, which govern how and when users will be required to go through the 2-step login process.
Two-Factor Authentication
Require 2-step verification when users log in to REDCap.
Two-factor settings:
Enforce two-factor authentication ONLY for Table-based users?
Only applicable if using an "X & Table-based" authentication method. Otherwise, this is ignored.
Notice: If "Yes" is selected, non-Table-based users will be EXEMPT from 2FA and from all 2FA enforcement settings.
Enforce two-factor authentication only for certain IP addresses?
You can enforce two-factor on all users OR enforce it on all users except for those within a specified IP address range. For example, if you know the IP ranges of computers on your institution's local network or VPN, then you can enforce two-factor only for users accessing REDCap from outside your institution.
IP address exceptions: You may enter IPv4 address ranges in either wildcard format with asterisks OR as a range with hyphen. IPv6 subnet masks may also be used. In addition to ranges, individual IP addresses may be used. All IP addresses and ranges must be separated by commas. Example: 1.2.3.*, 1.2.3.0-1.2.3.255, 21DA:00D3:0000:2F3B::/64
Also include all private network IP addresses in the IP exceptions (10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, 192.168.0.0-192.168.255.255)
Authentication interval: Trust a device's two-factor login for X days?
If enabled, a user performing two-factor login will be given the option to have their device/computer be remembered for X days during which they will not have to perform two-factor login but only log in with their username/password.
Days, 0 = Disabled   (Use decimals for partial days)
(Optional) Secondary authentication interval for specific IP address ranges
If desired, you can set an alternative authentication interval for devices in certain IP ranges. For example, you may want to set the interval to 30 days for users on a semi-secure network but set it to 1 day for users not on a secure network at all. You can set the interval to X days that the user's device will be trusted if within a given IP range.
Days, 0 = Disabled   (Use decimals for partial days)
Apply the authentication interval above to these IP ranges only:

You may enter IPv4 address ranges in either wildcard format with asterisks OR as a range with hyphen. IPv6 subnet masks may also be used. In addition to ranges, individual IP addresses may be used. All IP addresses and ranges must be separated by commas. Example: 1.2.3.*, 1.2.3.0-1.2.3.255, 21DA:00D3:0000:2F3B::/64
Allow users to e-sign using their Two-Factor Authentication 6-digit PIN in place of their password.
Used specifically when performing an e-signature on data entry forms or when utilizing the 'File Upload' field enhancement feature when uploading a file on a data entry form (often used for 21 CFR Part 11 compliance for FDA trials). NOTE: This feature cannot be used with the Duo Two-Factor option.
Two-factor login options:
(Optional) Enable the Google/Microsoft Authenticator app option for two-factor authentication?
If enabled, the 'Google Authenticator/Microsoft Authenticator' option can be used for two-factor auth, in which the user can obtain the 6-digit verification code from the Google Authenticator or Microsoft Authenticator app on their mobile device.
NOTE: Before using the app for two-factor auth, the user must first set up the Google Authenticator app or Microsoft Authenticator using the instructions and QR code on their Profile page.
(Optional) Enable the email option for two-factor authentication?
If enabled, the email option can be used for two-factor auth, in which the user can obtain the 6-digit verification code via their primary email that is registered in their REDCap account.
NOTE: The email will originate from your administrator account gustavo.lara@hhs.texas.gov
In most cases, it is good to leave this option enabled as a last resort for users just in case they are not able to use any of the other options for whatever reason.
(Optional) Enable the Twilio SMS option for two-factor authentication?
If enabled, the 'SMS' option can be used for two-factor auth, in which an SMS text message containing the 6-digit verification code can be sent to a user's mobile device using the Twilio web service.
Test the service:   
Note: In order to use the Twilio service, the REDCap web server must be able to make outbound HTTP/HTTPS requests to the following URL: https://api.twilio.com. For more information on Twilio, see https://www.twilio.com.
Twilio configuration settings
Before using this feature, you must first set up a Twilio account and obtain the required info below. How do I do this?
Twilio Account SID
Twilio Auth Token Show auth token
Twilio phone number
Alternate Twilio phone number for Voice Call verification option only (optional)
(If provided, Voice Call verification will be made from this number, whereas SMS verification will come from the first phone number above. If left blank, the first phone number above will be used for both SMS and Voice Call verification.)
(Optional) Enable the Duo for two-factor authentication?
If enabled, the 'Duo' option can be used for two-factor auth, in which the Duo mobile app or website is utilized for completing the login process.
Duo configuration settings
Before using this feature, you must first set up a Duo account and obtain the required info below. How do I do this?
Duo Integration key
Duo Secret key Show secret key
Duo API hostname

Login Settings (not applicable to Shibboleth authentication)

Auto logout time Minutes, 0 = timer off
Users will get a two-minute warning before they are automatically logged out if they do not have any activity in REDCap after this amount of time.
Login Logo
URL for custom logo to be displayed when user logs in to REDCap (max width: 750 pixels)
Custom login text
Custom text to display on the login page (It will appear above the login form, and if a login logo is used, it will appear immediately below the logo.)
Number of failed login attempts before user is locked out for a specified amount of time, which is set below. 0 = Disabled
Amount of time user will be locked out after having failed login attempts exceeding the limit set above. Minutes, 0 = Disabled
Login Page: Disable autocomplete feature in user's browser for username/password fields on REDCap login page?
NOTE: Disabling autocomplete increases security during login, especially for public computer usage.

Additional Table-based Authentication Settings:
Password recovery custom text
Set custom text that is included in the email to the user after entering an INVALID username when attempting to recover their password.
If left blank, the following text will be displayed instead:
"The password for the user XXXXXX cannot be reset in REDCap because it can only be reset using an outside authentication resource at your institution."

NOTE: Password recovery custom text can be be used when utilizing one of the 'X & Table-based' authentication methods in which external users might mistakenly attempt to reset their password, which is not possible using REDCap. For example, you may provide a link to direct them to the correct place to reset their password for their external account.
Enforce password re-use limit?
If set to 'Yes', it will not allow users to use their 5 most recent passwords as the value of a new password.
Force users to change their password after a specified number of days. Days, 0 = Disabled
Users will be prompted to change their password before the expiration occurs.
Password Minimum Length
Value entered should be integer (between 6 and 99).
If left blank, will default to the value 9.
Password Complexity
NOTE: Allowed special characters includes the following:
!@#$%^&*()/_+|~=’,-*+:\";?. (excluding ><\ )

Additional Google OAuth2 Authentication Settings:

Google OAuth2 setup instructions:
In order to use Google OAuth2 authentication, you must 1) go to the Google Developers Console and create a new project on that webpage (you may name the project whatever you wish (e.g. "REDCap Auth"). Note: You may want to avoid logging in to that page using your personal Google account since you will be creating Google API credentials used by REDCap at your institution. 2.) Once you have created the new project on the Google Developers Console webpage, select 'Credentials' under the 'APIs & auth' section on the left-hand menu. On the Credentials page under the OAuth section, click the button to create a new Client ID, and select the 'web application' as the application type. On the next screen, all you have to provide is the Product Name (e.g., 'REDCap'), and click the Save button. You may leave the 'Authorized JavaScript Origins' box blank (it is not needed here), but be sure to enter the following URL into the 'Authorized Redirect URIs' text box (ending both with and without a backslash): https://chi-redcap.dshs.texas.gov/redcap/ 3.) Once the Client ID has been created, it will auto-generate a Client ID name and a Client Secret. Copy those values into the text fields below so that REDCap may use them to authenticate with Google.
Google API Client ID
Google API Client Secret

Additional Microsoft Entra ID (formerly Azure AD) Authentication Settings:

The following 4 fields are for configuring the Microsoft Entra ID authentication. Information about the client id and client secret can be found here: (https://docs.microsoft.com/en-us/azure/storage/common/storage-auth-aad-app?tabs=dotnet).
API Client ID
API Client Secret
Endpoint Version
Version 2.0 endpoints allow for multi-tenant authentication into REDCap. To use 2.0 endpoints with REDCap, log into your Azure portal for App registrations, click the Authorization blade, and enable accounts in any organizational directory under the Supported account type field. Differences between the endpoint versions are summarized here: https://devblogs.microsoft.com/premier-developer/azure-ad-endpoint-v1-vs-v2/
Tenant
Provide the GUID value of your tenant if not using 'common'. If left blank, 'common' will be used. Applicable to both Endpoint V1 and V2.

Default value: common
AD attribute to use for REDCap username (Endpoint V1 and V2)
'userPrincipalName' will use the user's fully qualified username as their REDCap username, for example username@domain.com. 'onPremisesSamAccountName' will use the user's legacy domain username if syncing from your on-premises domain, for example 'username'
Primary Admin
The first time this user logs in, they will be given full admin privileges.
Secondary Admin
Same as above, just a backup admin. The first time this user logs in, they will be given full admin privileges.
(optional) Microsoft Entra ID button text on REDCap login page
Provide the button text for the Microsoft Entra ID button on the REDCap login page when users choose between 'Local REDCap Login' and 'Microsoft Entra ID'. If left empty, the button text will default to 'Microsoft Entra ID'. Note: This setting is only used for Microsoft Entra ID & Table-based authentication.

Additional OpenID Connect Authentication Settings:

The following fields are for configuring the OpenID Connect integration. Please note that the following attributes should be set accordingly on the Identity Provider server:
REDIRECT_URL = https://chi-redcap.dshs.texas.gov/redcap/index.php
POST_LOGOUT_REDIRECT_URI = https://chi-redcap.dshs.texas.gov/redcap/index.php?logout=1
Client ID
Additional scope (optional)
In certain cases, such as when using OIDC for Azure B2C, the Application (client) ID might need to be provided as the additional scope in order for authentication to work correctly.
Client Secret
Provider Base URL
Provider Metadata Document URL
Metadata Document URL typically ends with /.well-known/openid-configuration
Attribute to use for REDCap username
This OIDC attribute will serve as the authenticated user's REDCap username after logging in. If the selected attribute does not have a value for the user, it will revert to using the user's associated email address to serve as their username.
Response Mode option (response_mode)
If you do not know what it should be, leave it as the default.
Primary Admin
The first time this user logs in, they will be given full admin privileges.
Secondary Admin
Same as above, just a backup admin. The first time this user logs in, they will be given full admin privileges.
(optional) OpenID Connect button text on REDCap login page
Provide the button text for the OpenID Connect button on the REDCap login page when users choose between 'Local REDCap Login' and 'OpenID Connect'. If left empty, the button text will default to 'OpenID Connect'. Note: This setting is only used for OpenID Connect & Table-based authentication.
(optional) URL for Custom Logout Page
(Full URL with qualifiers)

Additional Shibboleth Authentication Settings:
Documentation on How to Configure Shibboleth Options
Shibboleth Username Login Field
Name of the server variable that contains the user's username that Shibboleth defines in PHP (e.g. $_SERVER['REMOTE_USER'])
URL for Shibboleth Logout Page
(Full URL with qualifiers)

Shibboleth User Information Settings:

When a user logs in to REDCap for the first time, REDCap can automatically set their name and email address using the information supplied by Shibboleth. These settings determine whether REDCap will do that and which Server fields REDCap will use.
Set user information using data from Shibboleth
If Enabled, REDCap will populate user information with values provided by Shibboleth. If Disabled, users will be shown a screen to set their own user information when they log in for the first time.
Set user information on each login
If set to 'Yes,' then REDCap will override the existing values for user first name, last name, and email address using information from Shibboleth. This is useful if you want changes to users' personal information made in the identity provider's database to be immediately reflected in REDCap. If set to 'No,' then user information will only be set when logging in to REDCap for the first time.
Shibboleth User First Name Field
Name of the server variable that contains the user's first (given) name that Shibboleth defines in PHP (e.g., $_SERVER['givenName']). Default value is 'givenName'
Shibboleth User Last Name Field
Name of the server variable that contains the user's last (family) name that Shibboleth defines in PHP (e.g., $_SERVER['sn']). Default value is 'sn'
Shibboleth User Email Field
Name of the server variable that contains the user's email address that Shibboleth defines in PHP (e.g., $_SERVER['mail']). Default value is 'mail'

Shibboleth & Table Splash Page Customization:
Default login method
Table login selection title
Clickable text to use table-based login

Shibboleth Login Options
Shibboleth login selection title
Clickable text to use Shibboleth login
Shibboleth login descriptive text
Descriptive text displayed with Shibboleth login
Shibboleth Link Image URL
URL for image to be displayed to link to server's Shibboleth login
URL for Shibboleth SP Session Initiator
If left blank, will default to the value stored in $_SERVER['Shib-Handler']
Additional IdP Controls

Australian Access Federation (AAF) Authentication Settings:

The following fields are for configuring Australian Access Federation (AAF) authentication. See the REDCap Community guide on setting up AAF RapidConnect Authentication for detailed instructions.
Access URL (required)
The URL that AAF provides you when registering a service
Audience URL (required)
The URL that authenticating users are redirected to upon authenticating. This is typically the REDCap base URL
Issuer URL (required)
The URL of the federation issuing the authentication token. This should be https://rapid.test.aaf.edu.au for test/development services and https://rapid.aaf.edu.au for production services.
Local identifier
This value in the AAF eduPersonScopedAffiliation attribute identifies a local. Multiple entries, one entry per line, may be used here, in which a user whose eduScopedPersonAffiliation attribute matches any of the supplied identifiers will be treated as a local.
Example:
staff@university1.edu.au
student@university2.edu.au
See the AAF Attribute Validator to check your own attributes for reference.
Allow locals to create/copy projects?
This setting will override the default setting for new users (see User Settings), which should be set to 'No' if you want to only allow locals to create/copy projects.
Display users on 'Email Users' page?
AAF attribute to be used as username
While AAF recommends using eduPersonTargetedID as a user's primary identifier as, unlike mail, it is guaranteed to never change for an individual, the mail attribute is most typically used as a username. eduPersonTargetedID is a long, non-human readable string. Using cn (common name) or displayname are discouraged as they may lead to clashes between individuals with the same name.

Additional SAMS Authentication Settings:
URL for SAMS Logout Page
(Full URL with qualifiers)

Other Security Settings:
Domain allowlist for cross-domain HTTP access control (optional)
By default, for flexibility purposes, AJAX requests (via JavaScript) can be made to REDCap from any domain/URL. If you wish to restrict this so that only certain domains can make cross-domain AJAX requests to REDCap, then you will need to set the domain name of all allowed access control origins (i.e., the domain of the URLs) in the text box to the right. If the text box is left blank (default), then any domain will be able to make cross-domain AJAX requests to REDCap. Restricting access control to specific domains is generally considered to make REDCap more secure to prevent against possible Cross-Site Scripting attacks by malicious users.

Leave blank to allow cross-domain access from any domain. Only enter the domain name (not a full URL) with each domain on a separate line.
Example:
http://example.com
http://www.mysite.edu
Clickjacking prevention
By default, a REDCap page can be embedded in an iframe on a page on any website. In some cases, this is useful, such as embedding surveys into other websites, but there is potential for abuse in which some malicious users may try to trick other users using a technique called clickjacking. If you wish to restrict this so that other websites cannot embed REDCap pages (in order to prevent clickjacking), then you set the option above. If you set it to 'Allow...', then any domain on the web will be able to embed a REDCap page (assuming this REDCap installation is publicly available to the web). Restricting access control from external websites is generally considered to make REDCap more secure to prevent against possible clickjacking attacks by malicious users. Technical note: Setting this to 'Prevent...' will force the HTTP header 'X-Frame-Options: SAMEORIGIN' to be added.
Restricted file types for uploaded files
Provide a list of all disallowed file types/extensions (e.g., exe) in order to prevent users from uploading files of these types into REDCap (often for security purposes). This setting will be applied to all places throughout REDCap where users are allowed to upload files. Please delimit each file type using a comma, semi-colon, or line break. Note: You do not need to provide different case sensitive variations for each file type.

Expand 
Example:
exe, js, msi, msp, jar, bat, cmd, com


The 'SMS' option for two-factor authentication utilizes a third-party web service called Twilio. To use this feature, you must have a Twilio account, which must be funded with money (since there is a cost for each SMS message sent). Before you begin the setup steps for Twilio SMS on this page, you must 1) set up your own Twilio account at www.twilio.com. Once your Twilio account has been created, you must 2) fund your account with some money (using the Billing page in Twilio) and then 3) purchase a phone number to be used for this REDCap project (see the Numbers page in Twilio).

Once a phone number has been purchased for the account, obtain the Account SID and Auth Token for your account (see the API Credentials section on the main Account Settings page), and then enter the Account SID, the Auth Token, and the phone number into the 'Twilio configuration settings' on this page. And as a final measure, click the 'Test Twilio credentials' button, which will verify the credentials entered to ensure that they will work and send SMS messages successfully.
The 'Duo' option for two-factor authentication utilizes a third-party web service called Duo. To use this feature, you must have a Duo account. Before you begin the setup steps for Duo on this page, you must 1) set up a Duo account at https://admin.duosecurity.com. Once your Duo account has been created, you must 2) go to the Duo Admin Panel and create a new Application (see the Applications item on the left-hand menu of that page) if you do not already have an application created, 3) set the application type as 'Web SDK', and 4) give it a name (e.g., 'REDCap production') and save it.

Once the application has been created for the account, obtain the Integration key, Secret key, and API hostname for that application. Then enter those values into the 'Duo configuration settings' on this page and save them.