Self-hosted applications

Cloudflare Access allows you to securely publish internal tools and applications to the Internet by providing an authentication layer between the end user and your origin server. You can use signals from your existing identity providers (IdPs), device posture providers, and other rules to control who can access your application.

Prerequisites

• An active domain on Cloudflare
• Domain uses either a full setup or a partial (CNAME) setup

1. Add your application to Access

1. In Zero Trust ↗, go to Access > Applications.

2. Select Add an application.

3. Select Self-hosted.

4. Enter any name for the application.

5. In Session Duration, choose how often the user’s application token should expire.

   Cloudflare checks every HTTP request to your application for a valid application token. If the user’s application token (and global token) has expired, they will be prompted to reauthenticate with the IdP. For more information, refer to Session management.

6. In Application domain, enter the domains that will represent the application.

   • Domains must belong to an active zone in your Cloudflare account. You can either select a domain from the dropdown or enter a custom domain that you control.
   • You can use wildcards to protect multiple parts of an application that share a root path.

7. (Optional) Configure App Launcher settings for the application.

8. Under Block pages, choose what end users will see when they are denied access to the application:

   • Cloudflare default: Reload the login page and display a block message below the Cloudflare Access logo. The default message is That account does not have access, or you can enter a custom message.
   • Redirect URL: Redirect to the specified website.
   • Custom page template: Display a custom block page hosted in Zero Trust.

9. Next, configure how users will authenticate:

   1. Select the Identity providers you want to enable for your application.

   2. (Recommended) If you plan to only allow access via a single IdP, turn on Instant Auth. End users will not be shown the Cloudflare Access login page. Instead, Cloudflare will redirect users directly to your SSO login event.

   3. (Optional) Under WARP authentication identity, allow users to authenticate to the application using their WARP session identity.

10. Select Next.

2. Add an Access policy

You can now configure an Access policy to control who can connect to your application.

1. Enter any name for your rule.

2. Specify a policy action.

3. Assign Access groups to reuse existing rules, or create new rules. You can add as many include, exception, or require statements as needed.

4. (Optional) Customize the login experience for users who match this policy:

   • Purpose justification
   • Temporary authentication

5. Select Next.

3. (Optional) Configure advanced settings

You can configure the following advanced settings for your application:

• Cross-Origin Resource Sharing (CORS)
• Cookie settings
• Automatic cloudflared authentication
• Browser rendering

To finish configuring the application, select Add application.

4. Connect your origin to Cloudflare

Next, set up a Cloudflare Tunnel to make your internal application available over the Internet.

5. Validate the Access token

To secure your origin, you must validate the application token issued by Cloudflare Access. Token validation ensures that any requests which bypass Cloudflare Access (for example, due to a network misconfiguration) are rejected.

One option is to configure the Cloudflare Tunnel daemon, cloudflared, to validate the token on your behalf. This is done by enabling Protect with Access in your Cloudflare Tunnel settings. Alternatively, if you do not wish to perform automatic validation with Cloudflare Tunnel, you can instead manually configure your origin to check all requests for a valid token.

Users can now connect to your self-hosted application after authenticating with Cloudflare Access.

Product compatibility

When using Access self-hosted applications, the majority of Cloudflare products will be compatible with your application.

However, the following products are not supported:

• Automatic Signed Exchanges
• Automatic Platform Optimization
• Zaraz

You can disable Automatic Signed Exchanges and Zaraz for a specific application - instead of across your entire zone - using a Configuration Rule scoped to the application domain.