1. 概述
在传统架构中，用户通常先接入网络，再在应用层进行身份认证。常见方式包括：通过 VPN 连接内网后登录应用，或在应用入口通过 OAuth / SSO 等协议进行身份校验。
这种“先连网、后认证”的模式，使网络接入与身份验证相分离，权限边界模糊、风险控制困难，一旦用户进入内网，便被默认“可信”，容易成为安全隐患的突破口。
飞网彻底颠覆这一模式，采用“先认证，后连网”的理念，实现基于身份驱动的访问控制：
用户必须先完成身份认证，才能连入网络、访问服务
网络即安全边界，服务默认对外不可见，未认证用户无法建立任何连接
权限与身份强绑定，简化策略配置、降低横向渗透风险
这一模式体现了“看不见、连不上、打不穿”的零信任安全模型，未认证即不可见，未授权即无法连接，未信任即无法访问，真正做到从源头阻断风险。
2. 飞网的三种网络身份认证集成模式
传统模式下，“网络信任”与“用户信任”是割裂的：进入网络≠合法用户，导致安全隐患。
飞网将“身份”作为唯一的访问入口，用户未认证即无法连入网络，天然具备“零信任”特性。
网络访问与身份强绑定，大幅降低内部横向移动风险，特别适合远程办公、零信任架构、安全合规需求场景。
为满足不同场景需求，飞网提供三种身份认证模式，帮助业务系统实现身份传递与安全访问：
| 模式 | 应用改造 | 适用网络环境 |
|---|---|---|
| Serve 模式 | 低 | 纯内部资源、快速部署 |
| Nginx 模式 | 低 | 纯内部资源，兼顾部分对外服务 |
| OAuth 模式 | 中 | 需统一身份入口及支持 OIDC 协议 |
每种模式在实现原理和适用范围上有所差异，后续章节将逐一介绍。
2.1 Serve 模式 —— 零配置、快速上线(详细配置请点击跳转)
Serve 模式是最简单的集成方式，无需部署额外服务，（可微量调整业务代码读取身份信息，可选）。
例如，下面这条命令即可将本地服务通过 HTTPS 暴露在飞网网络中，并自动启用身份认证：
gmzta service --https=443 80802.1.1身份信息自动注入
飞网会将用户身份通过 HTTP 头注入给后端服务，例如：
Gmzta-User: alice@example.com
Gmzta-Name: alice
Gmzta-Profile-Picture: URL_ADDRESS.com/avatar.png
Gmzta-GmztaNet：acme.gmzta.net2.1.2你的应用只需读取这些头即可“识别用户”。
2.1.3🧩 特点
零部署成本，无需配置反向代理
支持 HTTPS 自动证书管理
先认证后连接：未经身份验证的用户无法进入网络，阻断潜在风险于网络边界之外
全流量加密：全流量端到端加密，无需额外配置
2.2 Nginx 模式 —— 灵活配置、灵活部署(详细配置请点击跳转)
Nginx 模式是 Serve 模式的增强版本，支持更灵活的配置，便于根据业务需求自由扩展。
如果你已经在内网通过 NGINX 统一代理多个服务，飞网提供了一种更优雅的集成方式：通过飞网的身份认证机制，为所有服务统一接入用户认证，无需改动原有服务逻辑（如需读取用户身份，可进行少量业务代码调整）。
通过此模式，你可以：
保证每一个请求都经过认证
使用飞网的身份体系对用户进行认证
只允许你的团队成员访问这些服务
甚至区分不同飞网的访问权限
将认证信息以 HTTP Header 的形式传递到后端
后端无需再次实现登录认证逻辑
2.2.1 工作原理
nginx-auth 是一个独立的认证服务，它监听一个 Unix Socket地址（而不是 TCP 端口），接收来自 NGINX 的认证请求，通过飞网的 API 获取发起请求的用户信息，并返回给 NGINX 进行访问控制。
飞网：提供身份认证（API）和安全连接
nginx-auth：负责接收请求，调用飞网获取身份信息并返回认证结果
NGINX：作为反向代理中间层，负责访问控制和请求转发
业务应用：无需改动，且可自行配置读取 Header 获取用户信（Header信息与Service相同）
# 将身份信息通过 Header 注入到后端应用，可自定义返回名称
proxy_set_header X-Webauth-GmztaUser "$auth_user";
proxy_set_header X-Webauth-GmztaName "$auth_name";
proxy_set_header X-Webauth-GmztaLogin "$auth_login";
proxy_set_header X-Webauth-GmztaNet "$auth_gmztanet";
proxy_set_header X-Webauth-Gmzta-Profile-Picture "$auth_profile_picture";2.2.2. 飞网接入模式 vs 传统接入模式 对比分析
此图展示了传统应用接入方式与飞网接入方式在架构、安全性和接入体验上的主要差异。
传统接入 vs 飞网接入 架构对比图
| 对比维度 | 传统接入模式 | 飞网接入模式（先认证后连接） |
|---|---|---|
| 接入流程 | 先连接网络，再进行应用层认证 | 完成身份认证后，方可建立网络连接 |
| 网络暴露 | 网关直接暴露公网，易被扫描、攻击 | 无公网暴露，服务不可被发现 |
| 安全边界 | 安全依赖于应用层 | 网络本身即为第一道身份防线 |
| 风险点 | 攻击者可在认证前发起探测/攻击请求 | 未认证用户无法建立连接，隔绝所有外部攻击 |
| 通信通道 | 明文传输或自建 VPN | 全流量端到端加密隧道 |
| 应用改造 | 应用需实现或集成认证逻辑 | 直接读取飞网注入的身份 Header，无需登录逻辑 |
| 身份传递方式 | 无 | 飞网自动注入标准 HTTP Header |
| 权限控制 | 分散在各个系统中，维护复杂 | 可统一在飞网侧集中控制 |
| 用户体验 | 登录流程多，依赖多套系统 | 统一认证，网络即登录，访问开箱即用 |
2.2.3🧩 特点
适配现有架构：适用于已有 NGINX 反向代理场景，几乎无需修改业务系统
隔离非成员访问：可设置只允许特定飞网用户访问
灵活拓展精细控制：结合 NGINX 配置与访问控制，可实现访问路径精细控制、静态资源保护等功能
全流量过滤：全流量必须经过nginx 认证，避免未认证用户访问
先认证后连接：未经身份验证的用户无法进入网络，阻断潜在风险于网络边界之外
2.3 OAuth 模式 —— 标准协议、无缝对接(详细配置请点击跳转)
OAuth 模式是飞网支持的第三种身份集成方案，基于标准的 OAuth2 / OpenID Connect（OIDC）协议，可与现有统一认证平台或支持 OIDC 的系统无缝对接。
当你希望将飞网作为标准的身份提供者（IDP）时，可通过飞网网络或入口网关统一对接各类应用，实现跨网络、跨系统的用户认证。
飞网在此模式下可嵌入现有统一认证体系，支持如下常见系统的标准集成：
内部管理平台
运营后台
自研系统
API Gateway
单点登录平台
前端门户网关
2.3.1 工作原理
用户访问第三方服务，通过入口网关或飞网网络跳转到 OAuth认证连接器 执行 OIDC 登录流程
OAuth认证连接器 与飞网交互，基于终端连接状态获取用户真实身份
OAuth认证连接器 返回标准 OIDC 凭证（如 id_token、access_token）
第三方服务根据 Token 验证用户身份并进行权限控制
2.3.2 飞网接入模式 vs 传统接入模式 对比分析
传统接入 vs 飞网接入结构对比图
客户端 + IdP 接入飞网
全飞网部署示意图
- 传统模式：依赖公网条件，部署繁琐、存在较高安全风险；
- 飞网接入：逐步替代公网架构，构建安全、自动化的访问通路；
- 全飞网模式：零公网依赖，极简部署体验，适合各种受限环境。
| 模式 | 描述 | 网络要求 | 安全性 |
|---|---|---|---|
| 传统模式（未接入飞网） | 传统 OAuth 或 SSO 架构，依赖公网 IdP 与服务地址 | 客户端、认证系统、后端服务均需公网、TLS、端口放行 | 🔒 低：明文暴露多，配置复杂、易出错 |
| 客户端+IdP 接入飞网 | 客户端和飞网 IdP 在飞网内网，后端服务保持公网 | 客户端经飞网连接 IdP，后端仍需公网访问 | 🔒 中：登录链路加密受控，后端仍在公网 |
| 全飞网模式（推荐） | 客户端、IdP 与后端服务均部署在飞网网络内 | 无需公网、域名、TLS 证书或端口放行 | 🔒 高：全链路加密、身份自动注入 |
2.3.3 🧩特点
标准协议接入：支持 OIDC，几乎所有主流应用都能无缝集成
统一认证入口：可作为主身份源，为多系统统一用户入口
先认证后连接：未经身份验证的用户无法进入网络，阻断潜在风险于网络边界之外
灵活拓展精细控制：可结合飞网的访问控制策略，实现精细的访问控制