How Access works


Cloudflare Access evaluates requests to your application and determines whether visitors are authorized based on policies you define.

When a user attempts to access your application, Cloudflare redirects them to a custom authentication screen where they choose a third-party identity provider (IdP) you have configured. Once the user has authenticated, Cloudflare applies your Access policies and, if the user is authorized, redirects them to your application. Cloudflare evaluates all subsequent requests for successful authentication.

Access creates a signed token for every user session. This provides the information used to identify the user and application they are accessing.

Access sessions are shared between all sites in your Cloudflare account. When a user successfully authenticates on one site and has permission to reach another, they can seamlessly move between them.

Access Generic

Access login flow

The diagram below illustrates the login flow for a user attempting to login to an application protected by Cloudflare Access. The numbers in the diagram correspond to the steps in the outline that follows.


  1. A user attempts to access your application. At Cloudflare’s Edge Network, before the request ever reaches your application, Access evaluates the request for a valid Cloudflare token or a valid CF_AUTHORIZATION cookie. In this example, the request does not yet have a token or cookie, so Cloudflare Access redirects the user to the login page, which presents a list of identity providers to authenticate against.

  2. The user selects an IdP. Once the user selects an IdP, Access redirects their request to that IdP.

  3. The login page for the IdP is displayed to the user.

  4. The user supplies their credentials. The user enters their credentials on the identity provider login page and clicks the login button to authenticate.

  5. The IdP generates an access token. On successful authentication, the IdP generates an access token and calls the callback URL, which returns the access token to Cloudflare.

  6. Cloudflare Access uses the token to fetch user information (email address, name, etc.).

  7. Cloudflare authorizes the user. Cloudflare Access applies the policies configured for the application and determines whether the user’s request is authorized.

  8. Cloudflare Access generates a JSON web token (JWT). If the user’s request is authorized, a JWT is injected into a CF_AUTHORIZATION cookie. The JWT is valid for a configurable duration you can revoke the token at any time.

  9. Cloudflare Access redirects the request to the origin server

  10. The user accesses your application.

For more on setting up Access to protect web applications, see Securing web applications.

Secure your origin server

To secure your application with Access’s edge-based control, it is important that no one can access your origin server directly. When using Access, secure your origin server as follows:

  1. Force all requests to your origin server through Cloudflare’s network using one of the methods below:

    • Set up Argo Tunnel. Argo Tunnel offers an easy way to securely expose web servers to the Internet without opening firewall ports and configuring access control lists. For details see Getting started in the Argo Tunnel developers documentation.

    • Limit connections to the origin so that only connections from Cloudflare IP ranges are allowed.

  2. Validate JSON web tokens (JWTs). Validating the header alone is not sufficient. You must also confirm the JWT and signature to avoid identity spoofing. For more, see Validating JSON web tokens.