An application must be using Cloudflare (you can see if a subdomain is on Cloudflare by checking for the orange cloud in the DNS tab) to use Access.
Login to the Cloudflare dashboard. Click the ‘Access’ tile in the nav bar to visit the Access configuration.
Each user of Cloudflare Access lives on their own authentication domain. This domain will show in the address bar while the user is authenticating onto your site. This domain will be shared for all the sites hosted on your Cloudflare account. This domain is necessary, as it is used by Cloudflare to store the cookie used to identify authenticated users.
Your identity provider is the service your user’s will login to to authenticate with your site. For example, if you use Google Apps, it’s common to link with Google as your identity provider. It should be a service you expect your user’s to already have an account with.
If you don’t have an identity provider, you can always use the ‘Password-less’ provider which will email your visitors to confirm their identity. The password-less provider should already be installed for you by default. If you wish to use an alternative provider like Google, Facebook, or Github to authenticate your visitors:
Select which identity provider you wish to add. The current supported identity providers are:
Follow the identity provider-specific options.
Access policies define who can and can’t visit a given location on your site.
@cloudflare.comto allow everyone in your organization.
Visit the subdomain or path you configured Access for, and observe you are now asked to login!
Now is the time to add policies to any portions of your site you would like to keep private (like development sites and internal resources), and to any external services which have subdomains on your site (like Box or Google Apps for Business).