前言

其实，原本CF Zero Trust是我非常看重并且准备用大量篇幅来介绍的功能集合，毕竟它可是能为企业提供全面的安全防护，加上其重要的组成部分warp+(原本使用warp关联自己Zero Trust的My Team之后既可免费使用warp+)，我随便一想就可以想出好多可用的场景。

可惜的是，6月过后，Free计划用户的warp(+)在国内基本全废，而一些企业级的功能个人用户大多都用不上，我也就没什么动力来写，所以最后有实际意义的也就剩下Zero Trust的Network和Access两部分了。

Zero Trust(零信任)

附加知识：关于零信任

什么是零信任？

“零信任” (Zero Trust) 是一种安全理念，它基于这样的假设：任何人或设备，无论是在网络内部还是外部，都不应该被默认信任。与传统的“验证既信任”的安全模型不同，零信任模型主张 永远不信任，始终验证。即便用户或设备已经通过身份验证，每次访问资源时仍需重新验证其身份和权限。

零信任的关键原则包括：

1. 持续验证：所有的访问请求都必须经过验证，不论请求者是内部用户还是外部用户。
2. 最小权限原则：用户或设备只能访问其工作所需的最小权限，避免不必要的访问权限扩大风险。
3. 细粒度控制：基于用户身份、设备健康状态、地理位置等多种因素进行访问控制，确保只有经过多维度验证的请求才能获得访问权限。

这种方法减少了依赖传统边界防护（如防火墙）的风险，更适合应对现代复杂的安全威胁和分布式环境。零信任理念在各行业得到了广泛应用，尤其是在远程办公和云计算环境中，确保无论用户在哪里，访问企业资源时都经过严格的验证和控制。

传统基于VPN的方案和零信任方案的比较

1. 信任模型

• 传统 VPN：默认信任内部网络，连接到 VPN 后，用户通常可以访问整个内部网络资源。这种模型假设内部网络是安全的。
• Zero Trust：从不信任任何用户或设备，无论其位置如何。每个访问请求都需要经过身份验证和授权。

2. 访问控制

• 传统 VPN：基于用户身份和网络位置进行访问控制，通常提供广泛的网络访问权限。
• Zero Trust：采用最小权限原则，确保用户和设备只能访问其所需的特定资源，限制潜在的攻击面。

3. 身份验证

• 传统 VPN：通常使用静态用户名和密码进行身份验证，可能缺乏多因素认证（MFA）。
• Zero Trust：强调强身份验证和多因素认证，确保每次访问请求都经过严格验证。

4. 监控和响应

• 传统 VPN：网络流量监控较少，难以实时识别异常活动。
• Zero Trust：持续监控用户和设备的行为，能够快速检测和响应可疑活动。

5. 网络架构

• 传统 VPN：通常依赖于集中式的网络架构，用户通过 VPN 访问核心网络。
• Zero Trust：采用分布式架构，将网络分段，减少攻击者在网络中的移动范围。

6. 适应性

• 传统 VPN：在远程办公和云计算普及的情况下，可能面临安全漏洞。
• Zero Trust：设计上适应现代的工作环境，能够更好地保护云服务和远程访问。

由前面的对比可以看出，传统 VPN 方案适合于较为简单的网络环境，但在安全性和灵活性上存在很大的局限，特别是现在移动办公场景日益增多的形式下。而 Zero Trust 方案则为现代复杂的 IT 环境提供了更为严格的安全措施，能够有效应对当今不断变化的威胁。

Network

Zero Trust的Network部分有2个功能：Tunnles和Routes，最重要的是Tunnels，这是目前对我的"家庭数据中心方案"在国内可行的最关键的支撑技术，理所当然的也是本文描述的重中之重。

CF Tunnel

什么是CF Tunnel？

CF Tunnel (以前称为 Argo Tunnel) 是一种安全、轻量级的网络隧道技术，允许用户通过CF的全球网络将内部服务或应用程序公开到互联网上，而无需暴露服务器的公共 IP 地址或开放端口，其基本功能如下：

1. 建立安全连接：

• CF Tunnel 在您的服务器与CF边缘网络之间创建了一条基于TCP协议的加密隧道，这意味着所有的流量都会通过CF网络进行路由，从而避免了直接暴露您的服务器。
• 当客户端（例如浏览器）访问应用程序时，流量先通过CF的网络，然后通过隧道传输到内部服务器。这确保了网络请求是通过CF的安全防护进行的。

2. 无需暴露公共 IP 地址：

• 传统上，暴露应用程序需要开放防火墙端口并暴露服务器的公共 IP 地址。然而，CF Tunnel 通过安全地代理所有流量，无需在防火墙上开放入站端口。

注：以上2点对于国内没有备案域名和公网IP又想建站的朋友(不止对于家庭数据中心，国内云主机也是一样)，这可是天大的福音。

3. 动态生成隧道：

• CF Tunnel 使用客户端工具(如 cloudflared)来启动与CF的双向隧道。用户可以轻松地将任意内部服务暴露给CF，无论是 HTTP、SSH 还是其他协议。
• 该隧道是动态生成的，具有灵活的配置能力，可以根据需要随时启动或终止隧道连接。

4. 高可用性与负载均衡：

• CF Tunnel 可以自动负载均衡流量，并在隧道失败时提供高可用性。CF的全球网络通过多个边缘节点确保流量路由的高效和冗余，从而提高应用程序的可用性。

注：第4点对于一般的用户而言其实没有什么太大的意义，但是，这一点却提供了很多潜在的高级功能可供挖掘。

CF Tunnel相关技术点详细介绍及实操

---

FBI Warning：由于CF Tunnel能实现诸多高级功能，导致要梳理清楚需要涉及大量专业知识和枯燥的原理分析，极容易造成不适(头晕、眼花、瞌睡)，而一般的常规使用又用不着那些所谓的高级功能，所以对技术细节不感兴趣的朋友可以自行跳过部分内容。

---

tunnel

什么是tunnel？

CF Tunnel的概念我们在上一节中已经讲过了，而CF Tunnel在Zero Trust的实际配置体现就是tunnel。

在实际创建tunnel时，我喜欢用物理位置为标准来创建tunnel，比如下图中的"wudihome"代表我的家庭数据中心，"tencentcloud"代表我的腾讯云服务器，"aliyuncloud"代表我的阿里云服务器(tunnel使用tunnel id来表示标识)：

注：用位置为标准来创建tunnel，在一般场景中是很容易理解的：一个逻辑隧道连接CF的网络和一个物理位置，不过，在非一般的场景(一个逻辑隧道同时连接CF的网络和多个物理位置)，其实就不太合适了，所以当tunnle涉及多个位置时，从运维的角度来讲应该给tunnel考虑更合理的命名方式(例如项目名称)不过我这里就懒得去折腾这个了。

tunnle常规使用场景

• 场景1、1个tunnel只包含一个位置

这个估计是绝大部份人的使用场景，要么是自家宽带，要么是一台云主机，相同点在于对CF Tunnel而言，都是一个位置(一个来源IP)。这种是最基本的tunnel使用场景，配置也非常简单，没啥可说的，不是本文的重点。

• 场景2、1个tunnel包含不止一个位置，且这些位置的服务交付性能差不多

可能的场景包括：家庭数据中心出口宽带可以多重拨号(且每重拨号有独立的IPv4公网IP地址)，那么每个拨号算一个位置(我的家庭数据中心是3拨，用了2拨给tunnel做出入口)，每个位置交付性能一样(因为都是对应wordpress主站点，只是从不同位置进来而已)；或者同时有多个云服务器，且这些云服务器性能差不多(比如都是2核2G4兆)。

• 场景3、1个Tunnel包含不止一个位置，且这些位置的服务交付性能有很大差别

还是以我自己为例，我的家庭数据中心本身就包含2个位置，而且还包含了腾讯云服务器节点，加起来有3个位置，这3个位置服务交付性能却有很大差别：家庭数据中心的2个位置性能一样，但是腾讯云轻量服务器(2核2G4兆)就很勉强的，只能说一般够用。

但是，当有大流量访问的时候(比如被DDOS攻击的时候)，差别就很明显了：我家里的wordpress所在机器性能更强(乞丐版M1 macmini)，并且前端还有WAF和负载均衡设备进行预处理，这样下来，面对已经通过CF清洗过一次(DDoS防护和WAF)的攻击流量来说，最终达到我主wordpress站点的异常攻击流量估计就剩个1%；加上即使我wordpress主站点down了，还能通过本地负载均衡设备自动把请求转到备用wordpress站点(部署在inter cpu的mini主机上)，所以对我来说，家庭数据中心wordpress站点的性能和安全方面，远胜过一台啥也没有的腾讯云服务器。

正因为场景3就是我实际遇到的场景，所以我才会考虑"只有当家庭数据中心故障时，腾讯云服务器才自动接管博客"的容灾方案(详见文章后面部分)。

注：反过来，一个位置也可以运行多个不同的tunnel，不过本文就不多说了，怕把大家头搞晕，如果有需要大家可以思考一下这种场景。

connector

什么是connector？

connector其实是从属于tunnel的一个概念，对应于tunnel中的"位置"：当同一个tunnel是由多个不同的物理位置组成时，tunnel就需要使用connector来区分不同的位置。

和tunnel使用tunnel id来进行标识类似，connector使用connector id来表示。

那么相同的位置和不同的位置是如何区分的呢？靠的是不同位置使用自己的connector连接到CF网络的时候，CF看到的不同位置的"来源IP地址"。

---

之所以"来源IP地址"要打引号，是因为对于有公网IP的位置和没有公网IP的位置观感上是不一样的。

有公网IP的位置(比如我的家庭数据中心)，我自己可以明确的定义运行connector的设备从哪条出口链路出去，而因为我3拨的每条链路都有IPv4的公网地址(天选之人没办法，试问现在还能多拨且每拨都有公网IPv4的人还有多少？更别说还有IPv6哟)，所以理论上我可以让最多3个不同的设备同时运行connector从不同的出口链路出去，从而营造出有3个不同的位置的效果(如果加上我的5G CPE路由器，可以打造4个位置～)，当然，一般情况下两个就足够了，毕竟这种本来只是一个物理位置的场景下，多个connector主要是用来做冗余，防止其中一个connector出问题引发的博客访问中断：

而如果位置没有固定的、自己的公网IP(比如没有公网IP的家庭宽带跑tunnel)，那么对于CF边缘网上看到位置的"来源IP"就不可控了，所以只能随缘，正常情况下一段时间内肯定只会对应于一个公网IP(可能是ipv4地址，也可能是ipv6地址，这个主要看运营商的NAT策略)。

---

当同一个tunnel里有多个connector时，会自动激活"多站点负载均衡和自动冗余"的高级功能：既回源请求会自动选择不同的connector(如果是使用的free计划，这个功能不可控)进行发送，同时当某个connector断掉的时候，回源请求会自动通过剩下的正常运行的connector进行发送。这些功能其实提供了很多潜在的高端玩法，包括：多个wordpress站点同时提供服务并实现全局负载均衡及冗余、主wordpress站点故障时能自动接管业务的容灾站点等等(仅仅是用wordpress举例，任何方式建站都行)。

注：关于回源(具体回源的概念参见CF系列教程第三部：家庭数据中心系列 cloudflare教程(三) 如何进入CF的边缘网络及如何选择适合的回源方式)方式的选择，如果源主机在国内，不管是哪种环境(云主机、家庭宽带)，我只推荐tunnel的方式回源：1、域名不用备案(缺点是不能使用国内CDN，但是CF本身有免费CDN，优化一下，还是能凑活着用的)，2、不需要公网IP(家庭数据中心有无公网IP都没关系)，3、不需要配置反向代理和SSL证书(因为是直接打通内网和应用的http端口通信)，4、完全没有暴漏源站IP(如果源站有公网IP的话)的风险，安全又省事，何乐而不为呢？

connector常规配置

其实connector的部署很简单，在CF的"Zero Trust"–"Networks"–"Tunnel"里可以看到已经创建的tunnel：

进入已有的tunnel，以wudihome为例：

选择适合自己的安装方式：

在不同位置部署connector其实本质上内容都是一样的(如果是同一种系统，比如debian，则运行的命令都是一样的)，最终tunnel里显示不同的connector id只是因为在CF看来这些位置的源IP不同而已(如果有多个connector，源IP却相同，我测试的结果是访问速度会大幅下降，感觉tunnel无法在这种情况下正确选择回源connector)。

Public Hostname

前面讲述的tunnel和connector这两个概念加在一起，只是提供一个逻辑上的打通CF网络和我们自己网络内部的基本通道而已(俗话说得好："要致富，先修路"，不过光有路也不行啊，还要把农产品通过交通工具运出去卖才能致富)，最后一步，需要通过域名将内部服务或应用程序安全地发布到互联网，这就是"public hostname"功能的作用(交通工具这不就来了嘛)，不过，在实际部署中，根据环境的不同，public hostname的设置方式(主要URL部分应用的IP地址)有所不同。

单Tunnle、单Connector(常规场景)

这是绝大多数个人站长遇到的场景，public hostname的添加按照如下图片步骤配置即可：

对于个人站长而言，通常都是单tunnel、单connector(只有一个位置)的部署方式，且connector和应用部署在同一台设备上，这种情况的URL设置成localhost:port的方式就行了。

注1：这种场景下的详细配置步骤参见我之前的文章：家庭数据中心系列 通过tunnel技术，让无公网IP的家庭宽带也能白嫖cloudflare实现快速建站(推荐)。

注2：localhost不要用127.0.0.1来替代。

单Tunnel、多connector(高端场景)

对于个人站长而言，这种场景相对较少(可能只有少部分高端人群才会遇到~)，除了多个connector对应于多个位置以外，很可能connector和应用还不是部署在同一台设备上，那么此时，URL中就不能和前一种场景一样闷着头填localhost:port就完事了。

但是，能不能实现多个站点的"多站点负载均衡和自动冗余"，最后一步正确设置URL却是最关键，甚至可能需要一点技巧：

其实关键就是上图红框中应该填什么地址，严格意义上来说，应该是填:"在部署connector的节点看来，应用的IP地址是什么"，下面分3种场景讨论。

• 1、多个connector，且应用和connector位于同一台设备

如果不止一台设备部署connector，比如一台阿里云的服务器，一台腾讯云的服务器，分别部署了同一个tunnel对应的2个connector(在tunnel中对应2个connector id)，且两台服务器上部署的应用(比如wordpress)都是同样的端口(比如80端口)，那么红框中应该填写"localhost:80"，这样一来，访问请求不管是被CF分配到哪个connector，到达的哪台服务器，都能通过"localhost:80"访问自身安装的wordpress，这就是最基本的"多站点负载均衡和自动冗余"部署方式。

注：似乎还有人采用这种方式，将多个家庭宽带当成同一个tunnel下连接的多个connector，用多个connector来分散DDoS攻击时的流量和请求，不过在我看来，这其实是治标不治本，对于"真·家庭数据中心"解决方案来说，一个免费的WAF和一个开源的负载均衡软件就能轻松的解决CF DDoS防护和WAF两层过滤之后的漏网之鱼，等我把队列中的文章任务清空之后来写，毕竟，这也算是家庭数据中心安全方案的进阶版。

• 2、多个connector，但是应用和connector不在同一台设备

这种情况其实就是我的家庭数据中心的场景：我在家庭数据中心中用了两台debian的LXC(假设IP地址分别是172.16.0.1，172.16.0.2)来部署connector，这两个LXC上只部署了connector。

我的wordpress的真实地址是172.16.0.3(其实也不是，这个是WAF的地址，不过从外面看认为是wordpress的地址也无不可)，那么这个时候我上面的红框应该填写172.16.0.3，因为从部署connector(不管是哪台)的角度来看，通过172.16.0.3:80才能访问到wordpress。

注：connector和应用不在同一台设备上时，URL能填写的地址范围取决于部署connector的设备本身的路由，只要路由可达的都可以填。

• 3、同一个tunnel下，1、2种场景都有

还是以我的家庭数据中心为例：现在我在腾讯云服务器上也同样部署了"wudihome"这个tunnel的connector，这个时候适用第一种场景的localhost:80的写法；但是同时也存在家庭数据中心的connector，这个时候又要使用第二种场景172.16.0.3的写法，怎么解决这个矛盾？

这种场景就要灵活使用环回接口"loopback"了，只需要在腾讯云服务器上新建一个loopback接口并将其IP地址配置为172.16.0.3即可，这时，到达腾讯云服务器的目标地址为172.16.0.3的访问会被腾讯云服务器认为是对自身的访问从而正常处理该请求。

当然，真实的环境下，我不会同时开启所有connector(文章前面提到过，家庭数据中心wordpress主站点的性能和安全不是腾讯云服务器可比)，所以，默认腾讯云服务器上的connector是关闭的，只有当家庭数据中心出现故障(断电、断网)才会自动开启connector并接管wordpress主站点的服务(对该方案具体实施细节和相关操作感兴趣的朋友，可以参见文章：家庭数据中心系列 活用cloudflare tunnel实现wordpress主站点故障时灾备站点自动接管)。

注1：环回接口（Loopback Interface）是网络中的一种特殊接口，通常用于测试、调试以及本地主机通信，它最常见的 IP 地址是 127.0.0.1，这被称为“localhost”地址。不过，除了localhost地址之外，环回地址还有很多用法，最常见的就是本地企业网络中，三层设备配置动态路由协议(RIP、OSPF、IS-IS)时作为Router ID来使用，可以实现环回地址的全网可达，不管是用来管理三层设备还是排查路由问题都很方便。本文中的用法只是对环回接口最基础的使用而已，不过却是使我上面那篇容灾方案最终能够实现的一块重要的技术拼图。

注2：环回地址作为Router ID并实现全网可达，在"全网可访问性"以及"虚拟化与稳定性"这两个方面和Anycast IP实现的效果有一定的相似性，可以帮助大家理解Anycast IP技术的实现原理。

多协议支持

对于public hostname而言，并非只能发布基于http(s)协议的应用，还支持不少基于其他协议的应用的发布：

只不过，这些基于非http(s)协议的应用主要是通过CF Tunnel实现单点对接，不像http(s)应用那样支持多点访问或跨多个地点的优化(因为无法使用CF默认提供Anycast 技术)，所以导致这些应用的用途较为局限。

但是CF Zero Trust 仍然可以对这些非http(s)的应用提供身份验证、访问控制和日志记录等安全功能，所以，还是有一定价值的(聊胜于无～)。

Routes

---

注：这部分内容简单了解下即可，本来是配合warp+和My Team功能来使用的，可惜Free计划的用户在国内已经没法使用warp+了，只不过Network部分都写了Tunnel了，不写这个又显得文章结构不完整，不符合我的审美。

---

"Routes"是用于配置网络流量路由规则的部分，它允许你定义如何处理用户通过CF网络访问内部资源的流量。这是实现零信任架构的关键组成部分之一，确保所有流量都受到监控和控制。

Routes 功能的核心特点：

1. 流量控制：通过 Routes，可以定义哪些流量应该通过CF的 Zero Trust网络进行处理。这包括从用户设备到目标资源的连接路径，从而确保网络访问符合零信任的安全策略。
2. 策略应用：Routes 允许指定流量应用的策略规则，比如强制使用 VPN、验证身份或应用访问控制策略。这有助于增强安全性，确保只有经过验证的用户和设备能够访问内部资源。
3. 细粒度配置：你可以根据不同的子网、IP 地址范围或 DNS 名称来创建精细的路由规则，适应不同场景下的网络访问需求。

简单说明下实际的使用场景，在以前warp+可以用My Team功能配合的时候，如果我有多个位置，比如家庭数据中心(网段192.168.10.x/24)，对应tunnel为"wudihome"；腾讯云服务器(网段10.0.0.3/32)，对应tunnel为"tencentcloud"，那么，我可以如下设置Routes：

这时成功连接warp+(需已经正确关联my Team)之后，就可以直接访问家庭数据中心内部的192.168.10.x以及10.0.0.3了，这可比以前IPsec vpn的点对点访问高级多了，不过现在warp+不能用了，也无法享受了。当然，我虽然有这种需求，只不过却不是用warp+来实现，有tailscale，还要啥自行车？

注：对warp如何使用感兴趣且环境允许使用的朋友，可以我参看之前的文章：家庭数据中心系列 合理利用cloudflare WARP来提高自己访问网站的速度(桌面版)和家庭数据中心系列 云主机上部署cloudflare warp来提高网络访问速度(Linux cli版)。

Access

什么是Access？

Zero Trust 的 Access 功能是为企业提供基于零信任架构的安全访问控制解决方案。它确保只有经过身份验证和授权的用户才能访问特定的应用和资源，无论这些资源位于本地数据中心还是云端。

说人话就是：通过Access可以将内部应用直接发布到公网上，并通过各种身份验证方式和安全措施在保证应用安全的同时，让真正需要的人快速访问应用。

主要功能：

1. 身份验证集成：

• 支持与多个身份提供商（如 google、github、facebook）集成，实现单点登录（SSO）和多因素身份验证（MFA），确保只有经过验证的用户才能访问受保护的资源。

2. 基于策略的访问控制：
   • 管理员可以创建细粒度的访问策略，基于用户身份、位置、设备属性等条件来控制谁可以访问特定的应用程序和资源。这种策略驱动的访问控制提高了安全性和灵活性。

3. 无 VPN 访问：

• CF Access 提供了一种无 VPN 的替代方案，允许用户通过CF的全球网络直接访问公司内部资源，从而减少 VPN 的复杂性和延迟，同时提升安全性。

4. 审核和日志记录：

• Access 提供详细的日志记录和审核功能，管理员可以跟踪谁何时访问了哪些资源，增强了对访问活动的可见性和审计能力。

可惜的是，Access部分绝大部分的认证功能要么需要第三方配合(比如前面提到的google、github、facebook等)，要么需要和企业网站的开发结合(比如各种Token)，而对于个人用户而言，真正简单实用的认证方法基本只有通过邮箱收取OTP(one-time pin，一次性pin码)来实现。

使用Access为自己发布的web应用添加认证功能

1、选择需要发布的web应用

需要一个应用做示范，所以我新建了一个"ac86u.tangwudi.com"的域名，关联我内网的华硕ac86u的登录界面，此时访问能正常打开：

2、提前创建一个Access Group

在添加应用时，应用需要属于某一个"Access Groups"(访问组)，所以需要提前创建：

---

Selector(选择器)还有一个邮箱方式的选项"Emails ending in"：

这种方式适合多个邮件地址有同一个邮箱后缀的情况(比如企业邮箱)，不过设置了CF电子邮件路由功能的朋友(参见文章：)，拥有自己域名后缀的邮箱，也可以使用这种方式。这时只要为每个朋友都分配一个域名后缀的邮箱账号(关联他们自己的真实邮箱)，就可以只设置这一条身份验证规则，所有的朋友都可以访问你发布的需要验证的应用了。

---

3、添加应用

使用Access为自己的web应用添加认证功能按照如下流程进行操作即可。

添加一个应用(Application)：

选择自托管方式(Self-hosted)：

为应用设置参数：

这一页其他选项图省事的话可以都保持默认，不过也有些选项可以花点精力，比如logo：

设置完之后选择Next继续下一页设置：

设置应用的策略名和策略的行为：

之后直接点击右下角的"Next"继续下一页设置：

最后添加应用：

创建应用完成：

4、测试身份验证效果

重新打开"ac86u.tangwudi.com"，界面变成了这样：

立马高大上了许多，在Email框里输入前面设置的邮箱地址并发送验证码：


然后就可以看到真实的应用界面了，地址也是真实的地址了(之前认证时是my team的地址)：

附加知识：OAuth

其实，对于个人用户而言，除了通过邮箱获取OTP码这种方式进行验证以外(简单、实用但是较low)，还可以通过OAuth的方式来使用第三方的身份验证(google、github、facebook等等)。

什么是OAuth？

OAuth（开放授权）是一种开放标准，允许用户授权第三方应用程序访问其在某个服务上的信息，而无需分享他们的用户名和密码。它通常用于社交媒体、在线服务和应用程序之间的安全访问。

基本概念：

1. 资源所有者 ：用户，拥有资源（如个人信息、照片等）。
2. 客户端 ：请求访问资源的应用程序或服务（如社交媒体应用）。
3. 授权服务器 ：验证用户身份并颁发访问令牌的服务器（如Google或Facebook的身份验证服务）。
4. 资源服务器 ：存储用户资源的服务器（如存储用户照片的服务器）。

工作流程：

1. 用户在客户端应用上点击“使用XXX登录”按钮。
2. 客户端将用户重定向到授权服务器，用户在此处登录并授权客户端访问其资源。
3. 授权服务器验证用户身份后，返回一个授权码给客户端。
4. 客户端使用授权码向授权服务器请求访问令牌。
5. 授权服务器验证授权码并返回访问令牌给客户端。
6. 客户端使用访问令牌向资源服务器请求用户的资源。

这个大家平时在国内生活中其实也经常用到，就是登录app的时候使用qq或者微信账号等授权。

如何添加第三方OAuth？

按照以下步骤添加第三方OAuth：

选择一个idp(身份提供商)，以github为例(前提是你得有github的账号)：

然后跟着右边的教程进行设置就好：

最后成功后会多出一个GitHub的验证选项：

使用这种方式的结果，是任何拥有github账号的用户都能通过验证，如果要进一步控制哪些有github账号的人可以访问你的应用，就需要在Zero Trust中设置额外的访问控制策略，例如基于用户组、角色等进行更细粒度的控制，这些大家有兴趣可以研究下，我就不去折腾了，主要没啥用，设置位置就在这里：

当然，单独一个github的认证也不大气，所以可以把其他的也加上，这样有任何一个idp的账号就可以直接发起登录申请(显得很高大上，盟友众多的感觉～)，但是，最后能不能通过认证，就要看你设置的条件了。

后话

本身来讲，CF Tunnel功能虽然很强大，但是也不过是和公网地址回源并存的2种常规回源选择之一，只从单个源站回源的角度来说，相对于公网地址回源方式，只能说各有优劣势：
1、加密隧道

对于其他国家的网络来说，用不用加密隧道都无所谓，公网地址回源方式中，使用https对源站回源一样可以保证回源的安全性。
2、没有公网IP

对于其他国家的网络来说，没有IPv4总有IPv6，就算没有申请难度也不高，再不济随便找个本国的云主机也有公网IP(至少有IPv6)，所以对于建站来说公网IP问题很好解决。

但是对于使用国内环境建站来说，采用公网IP地址回源的方式就必须要备案，不管采用域名方式还是纯IP：

加上公网IP获取困难、家庭宽带运营商频繁清理入向的对未备案域名的http(s)类型的访问，基本已经把公网地址回源的方式直接废了，所以，这个时候CF Tunnel提供的基于tcp协议全加密隧道、不需要公网IP的回源方式直接就无敌了好不？

当然，使用在CF Tunnel方式建站，默认情况下也有缺点：
1、回源慢

如果源站在国内，回源慢这个没法解决，因为是从国外数据中心来回源，来回跨太平洋，快才奇怪。
2、访问慢

开启小橙云后发布的应用，解析的IP都是海外IP(对Free计划的站长来说)，所以算是海外建站，这个时候从国内直接访问速度感人。

这两方面原因加在一起，导致没做优化之前从国内访问只能算勉强可用，所以，如果正儿八经的以国内用户为主要目标且要求国内访问体验好的，还是老老实实走备案流程，然后使用国内CDN供应商提供的加速服务，这样访问体验好且不用折腾，当然，随之而来的付费CDN流量被恶意消耗、DDoS防护费用昂贵也是必须面对的事情。

那么，能不能又使用CF Tunnel方式建站，又想国内访问体验不算太差呢？

也不是不行，答案就隐藏在之前的cloudflare系列教程中～。