尧图网页设计 
Authelia 实战用 Basic Auth 与服务账号保护无认证后端应用【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia本指南以 Authelia 与 Traefik 为示例讲解如何借助ForwardAuth 中间件为没有任何内置认证的后端应用API 服务器、监控面板、日志聚合器等统一接入认证同时通过Basic Authentication 与服务账号Service Accounts为监控探活、CI/CD、日志上报等程序化访问开放入口。读完本文你将掌握一套人走 Web 门户、机走 Basic Auth、ACL 按组分流的完整落地方案并能据此为任意受支持的反向代理实现同样的效果。本文依据仓库内指南 Securing Applications with Basic Auth 展开并结合 Authelia 源码中的授权端点实现与 访问控制配置 进行深入解读。适用场景与前置假设当后端应用本身没有内置认证或认证被关闭时你需要一种不修改应用代码即可完成的接入方案。典型场景包括暴露在公网、希望只让已认证用户访问的自建 Web 应用需要同时服务浏览器用户和自动化系统监控工具、CI/CD 流水线、其他服务的 API日志/指标/追踪聚合器如 Loki、Mimir、Tempo 等本身不含认证需要让采集 Agent 以程序化方式安全上报。本指南建立在以下假设之上Authelia 已部署并运行且以 Traefik 作为其反向代理。需要说明的是虽然本指南显式使用 Traefik但同一目标状态也完全可以在其他受支持的反向代理上实现——根据 支持矩阵Caddy、HAProxy、Skipper 等同样使用ForwardAuth实现Envoy 使用ExtAuthzNGINX/SWAG/NGINX Proxy Manager 使用AuthRequest。目标后端应用没有内置认证。核心概念ForwardAuth把授权决策委托给外部服务ForwardAuth 允许代理Traefik把授权决策委托给外部服务。当客户端请求受 forward auth 中间件保护的资源时Traefik 会把初始请求的头部与连接信息转发给认证服务器。认证服务器只有两种可能的响应OK初始请求继续发往后端资源服务器KO初始请求被拦截返回重定向或www-authenticate响应。这套机制把认证逻辑集中到 Authelia而不是依赖应用自身的实现或缺失的实现。从 Authelia 源码看ForwardAuth 实现通过读取X-Forwarded-Method、X-Forwarded-Proto、X-Forwarded-Host、X-Forwarded-URI头还原出被请求的对象再交给授权模块判定——这也是trustForwardHeader: true之所以必要的原因Traefik 必须把这些转发头完整传给 Authelia。Basic Authenticationbase64 编码的凭证传递Basic 认证以username:password格式将凭证做 base64 编码后通过Authorization: Basic encoded-stringHTTP 头传输。服务账号面向程序化访问的非人类用户服务账号是为程序化访问而设计的非人类用户。与常规用户账号不同它们通常使用长期凭证且不依赖交互式认证流程如 OpenID Connect。在本方案中Authelia 对待服务账号与普通用户并无区别——它不区分二者。但由于访问控制的默认策略是deny服务账号只能访问 ACL 规则中显式授权的应用。从安全角度这非常重要任何持有服务账号凭证的人都可能登录 Authelia Web 门户并访问该服务账号被授权的所有资源。最佳实践仅授予服务账号完成任务所需的最小权限并为每个应用或用例使用专用服务账号以限制潜在暴露面。架构与配置整个方案由四部分组成Traefik 的路由/服务/中间件、Authelia 用户库中的服务账号、Authelia 的 ACL 规则以及无需修改的被保护应用。Traefik 路由、服务与中间件以下配置让 Traefik 把请求路由到你的应用并用 Authelia 的 ForwardAuth 中间件保护它。路由器定义需要保护的域名myapp.example.com服务指向后端应用中间件配置则要求 Traefik 在放行前将所有请求交给 Authelia 校验http: routers: myapp-router: rule: Host(myapp.example.com) entrypoints: - https middlewares: - autheliafile service: myapp-service services: myapp-service: loadBalancer: servers: - url: http://myapp:80/ middlewares: authelia: forwardAuth: address: https://authelia:9091/api/authz/forward-auth trustForwardHeader: true authResponseHeaders: - Remote-User - Remote-Groups - Remote-Email - Remote-Name其中address指向 Authelia 的 ForwardAuth 授权端点/api/authz/forward-auth。从源码看这是 Authelia 服务器端点的预置实现之一server.go 配置中forward-auth端点默认绑定ForwardAuth实现与其并列的还有AuthRequest、ExtAuthz、Legacy等实现见 const.go。authResponseHeaders重要但可选它允许 Authelia 把用户信息用户名、组、邮箱透传给后端应用便于做日志或按用户定制功能。参见 Trusted Header SSO。这些响应头由 Authelia 在授权通过时写入。在 handler_authz_common.go 的handleAuthzAuthorizedStandard中可以看到响应 200 的同时会设置Remote-User用户名、Remote-Groups逗号分隔的组列表、Remote-Name显示名与Remote-Email邮箱头名常量定义在 const.go。测试用例 handler_authz_test.go 也验证了这些头会被正确回写。服务账号与普通用户同库、以组标识身份服务账号在 Authelia 用户库中配置方式与普通用户一致只是通过特定组来标识其身份。关键差异点组Groups同时包含myapp用于应用访问和service用于标识服务账号身份邮箱Email应使用监控/收件群组邮箱而非个人邮箱密码Password使用强度高、随机生成的密码64 字符因为它在程序化场景下使用不受多因素认证保护。人类用户如john只属于myapp组不含service因此会适用不同的认证要求users: my-service-account: displayname: My Service Account password: $argon2id$v19$m65536,t3,p2$BpLnfgDsc2WD8F2q$o/vzA4myCqZZ36bUGsDY//8mKUYNZZaR0t4MFFSsiM # digest for password email: my-service-accountexample.com groups: - myapp - service john: displayname: John Doe password: $argon2id$v19$m65536,t3,p2$BpLnfgDsc2WD8F2q$o/vzA4myCqZZ36bUGsDY//8mKUYNZZaR0t4MFFSsiM # digest for password email: john.doeauthelia.com groups: - myapp提示上面的密码哈希对应明文password仅作示例。生产环境请务必为服务账号生成独立、随机的强密码并使用 Authelia 提供的密码哈希生成工具。Authelia 访问控制规则按组成员资格分流认证强度以下 ACL 规则基于组成员资格建立不同的认证要求第一条规则同时拥有myapp与service组的用户即服务账号只需单因素认证one_factor这使 Basic Auth 能够正常工作第二条规则仅拥有myapp组的用户人类用户需要双因素认证two_factor强制他们通过 Web 界面完成第二因素。规则顺序至关重要。Authelia 对规则匹配有两个重要概念顺序匹配Sequential Order规则从上到下依次求值第一条完全匹配的规则生效。因此更具体的规则如服务账号的one_factor必须放在前面主体条件需要先完成认证Subject Criteria Requires Authentication在用户完成认证之前Authelia 无法得知其用户名与组。所以如果认证不满足规则就无法命中对应的subject。access_control: default_policy: deny rules: - domain: - myapp.example.com policy: one_factor subject: - [group:myapp, group:service] - domain: - myapp.example.com policy: two_factor subject: - group:myapp注意第一条规则的subject是嵌套列表[group:myapp, group:service]表示同时满足两个组条件这与普通列表满足其一即可的语义不同。借助该写法只有同时属于两个组的服务账号才会命中one_factor分支而普通用户落到第二条two_factor规则。这与 access-control.md 文档中关于规则求值顺序与主体条件的说明一致你还可以用authelia access-control check-policy命令验证某条请求到底命中哪条规则见 CLI 参考。被保护的应用零改造接入被保护应用即你的后端应用——API 服务器、Web 应用或任何需要保护的服务它不需要任何修改所有认证逻辑由 Authelia 处理应用只会在请求通过校验后才收到请求。如果应用需要知道访问者是谁可以读取 Authelia 透传的头如Remote-User、Remote-Groups来实现按用户定制或日志记录。这些头正是通过上文 Traefik 中间件的authResponseHeaders透传的。工作流程人类用户通过浏览器访问myapp.example.com被重定向到 Authelia 门户必须完成双因素认证才能获得访问权服务账号携带Authorization: Basic base64(username:password)头提交凭证即可绕过 Web 界面两种访问方式都由 Authelia 校验但根据组成员资格应用不同的 ACL 规则认证通过后请求带着额外的响应头转发到后端应用。从实现层面看Basic Auth 的校验发生在 Authelia 的认证策略中在 handler_authz_authn.go 中Authorization头按 scheme 分流Basicscheme 走handleGetBasic校验用户名密码并取得用户详情与认证级别Bearer则走 OIDC 流程。one_factor策略下 Basic Auth 即可满足认证级别这正是服务账号能用 Basic Auth 直连的原因而人类用户被two_factor规则强制走完整双因素流程。Basic Auth 的缓存与防爆破值得补充的是Authelia 对 Basic Auth 凭证校验做了性能与安全设计见 handler_authz_authn.go默认直接调用用户提供方如文件用户库或 LDAP的CheckUserPassword校验用户名与密码当配置了 Basic Auth 缓存存活期basic_auth_cache时会启用基于 HMAC-SHA256 的凭证缓存减少高频率程序化访问对认证后端的压力配合认证延迟timing attack delay机制可缓解针对 Basic Auth 的时序侧信道与暴力破解风险。验证浏览器访问验证在浏览器中打开https://myapp.example.com应被重定向到 Authelia以 John或其他用户身份登录并完成双因素认证应被重定向回你的应用。API 访问验证curl -u my-service-account:password https://myapp.example.com/-u参数会让 curl 自动构造Authorization: Basic base64(my-service-account:password)头。请求命中第一条 ACL 规则仅需单因素认证因此无需任何交互即可通过而后端应用会从Remote-User头读到my-service-account。常见用例监控与健康检查Uptime Kuma 等应用支持主动推送式健康检查应用周期性发送 API 请求上报当前状态。如果 Uptime Kuma 位于 Authelia 之后且认证已禁用你可以用服务账号放行这些推送 API 请求。若只想放行特定路径参见下文 路径级放行。日志与指标上报Loki、Mimir、Tempo 等日志/指标/追踪聚合器往往不自带认证本方案非常契合给采集 Agent 配置 Basic Auth 凭证即可向受保护的应用安全上报日志或指标。高级配置路径级放行Path Bypass如果只想对服务账号放行部分 API 路径而非整个 API可以借助访问控制的 resources 条件实现。下面的示例只允许myapp服务账号访问myapp.example.com/api/push/*而不允许其访问 myapp API 的其他部分access_control: default_policy: deny rules: - domain: - myapp.example.com policy: one_factor resources: - ^/api/push([/?].*)?$ subject: - [group:myapp, group:service]resources使用正则表达式匹配请求路径注意 Authelia 的正则区分大小写。将这条规则放在最前面使其先于其他更宽泛的规则被命中。关于resources的详细语义与示例参见 access-control.md 的 resources 小节。基于网络的访问控制你还可以通过访问控制中的networks选项限制服务账号允许使用的来源 IP 地址。例如仅允许监控探活主机或 CI 出口 IP 使用该服务账号从而显著缩小凭证泄露后的影响面。详见 access-control.md 的 networks 小节该选项支持 IP 地址、CIDR 网段以及网络别名alias的组合。安全注意事项实现 Authelia 服务账号时应牢记以下安全实践尽可能使用默认拒绝default deny策略确保服务账号只能访问被显式授权的资源只授予服务账号完成任务所需的最小权限由于服务账号绕过了多因素认证密码强度至关重要服务账号密码应至少 64 字符且随机生成避免在多个位置复用同一个服务账号应为不同场景分别建立服务账号这样既能精确定位被泄露的账号/机器也避免一次性在大量地方轮换凭证尽可能限制服务账号可用的来源 IP 地址利用networks条件定期审查在用服务账号及时清理不再使用的账号。小结本文围绕ForwardAuth 统一认证 服务账号 Basic Auth 程序化访问这一模式完整覆盖了 Traefik 中间件配置、服务账号用户库配置、按组分流的两级 ACL 规则、验证方法、监控/日志等典型用例、路径级与网络级的高级控制以及配套的安全实践。这套方案的价值在于后端应用零改造即可获得人走双因素门户、机走单因素 Basic Auth的差异化接入能力且认证决策全部集中在 Authelia 一处便于审计与治理。【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Authelia 实战：用 Basic Auth 与服务账号保护无认证后端应用
Authelia 实战用 Basic Auth 与服务账号保护无认证后端应用【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia本指南以 Authelia 与 Traefik 为示例讲解如何借助ForwardAuth 中间件为没有任何内置认证的后端应用API 服务器、监控面板、日志聚合器等统一接入认证同时通过Basic Authentication 与服务账号Service Accounts为监控探活、CI/CD、日志上报等程序化访问开放入口。读完本文你将掌握一套人走 Web 门户、机走 Basic Auth、ACL 按组分流的完整落地方案并能据此为任意受支持的反向代理实现同样的效果。本文依据仓库内指南 Securing Applications with Basic Auth 展开并结合 Authelia 源码中的授权端点实现与 访问控制配置 进行深入解读。适用场景与前置假设当后端应用本身没有内置认证或认证被关闭时你需要一种不修改应用代码即可完成的接入方案。典型场景包括暴露在公网、希望只让已认证用户访问的自建 Web 应用需要同时服务浏览器用户和自动化系统监控工具、CI/CD 流水线、其他服务的 API日志/指标/追踪聚合器如 Loki、Mimir、Tempo 等本身不含认证需要让采集 Agent 以程序化方式安全上报。本指南建立在以下假设之上Authelia 已部署并运行且以 Traefik 作为其反向代理。需要说明的是虽然本指南显式使用 Traefik但同一目标状态也完全可以在其他受支持的反向代理上实现——根据 支持矩阵Caddy、HAProxy、Skipper 等同样使用ForwardAuth实现Envoy 使用ExtAuthzNGINX/SWAG/NGINX Proxy Manager 使用AuthRequest。目标后端应用没有内置认证。核心概念ForwardAuth把授权决策委托给外部服务ForwardAuth 允许代理Traefik把授权决策委托给外部服务。当客户端请求受 forward auth 中间件保护的资源时Traefik 会把初始请求的头部与连接信息转发给认证服务器。认证服务器只有两种可能的响应OK初始请求继续发往后端资源服务器KO初始请求被拦截返回重定向或www-authenticate响应。这套机制把认证逻辑集中到 Authelia而不是依赖应用自身的实现或缺失的实现。从 Authelia 源码看ForwardAuth 实现通过读取X-Forwarded-Method、X-Forwarded-Proto、X-Forwarded-Host、X-Forwarded-URI头还原出被请求的对象再交给授权模块判定——这也是trustForwardHeader: true之所以必要的原因Traefik 必须把这些转发头完整传给 Authelia。Basic Authenticationbase64 编码的凭证传递Basic 认证以username:password格式将凭证做 base64 编码后通过Authorization: Basic encoded-stringHTTP 头传输。服务账号面向程序化访问的非人类用户服务账号是为程序化访问而设计的非人类用户。与常规用户账号不同它们通常使用长期凭证且不依赖交互式认证流程如 OpenID Connect。在本方案中Authelia 对待服务账号与普通用户并无区别——它不区分二者。但由于访问控制的默认策略是deny服务账号只能访问 ACL 规则中显式授权的应用。从安全角度这非常重要任何持有服务账号凭证的人都可能登录 Authelia Web 门户并访问该服务账号被授权的所有资源。最佳实践仅授予服务账号完成任务所需的最小权限并为每个应用或用例使用专用服务账号以限制潜在暴露面。架构与配置整个方案由四部分组成Traefik 的路由/服务/中间件、Authelia 用户库中的服务账号、Authelia 的 ACL 规则以及无需修改的被保护应用。Traefik 路由、服务与中间件以下配置让 Traefik 把请求路由到你的应用并用 Authelia 的 ForwardAuth 中间件保护它。路由器定义需要保护的域名myapp.example.com服务指向后端应用中间件配置则要求 Traefik 在放行前将所有请求交给 Authelia 校验http: routers: myapp-router: rule: Host(myapp.example.com) entrypoints: - https middlewares: - autheliafile service: myapp-service services: myapp-service: loadBalancer: servers: - url: http://myapp:80/ middlewares: authelia: forwardAuth: address: https://authelia:9091/api/authz/forward-auth trustForwardHeader: true authResponseHeaders: - Remote-User - Remote-Groups - Remote-Email - Remote-Name其中address指向 Authelia 的 ForwardAuth 授权端点/api/authz/forward-auth。从源码看这是 Authelia 服务器端点的预置实现之一server.go 配置中forward-auth端点默认绑定ForwardAuth实现与其并列的还有AuthRequest、ExtAuthz、Legacy等实现见 const.go。authResponseHeaders重要但可选它允许 Authelia 把用户信息用户名、组、邮箱透传给后端应用便于做日志或按用户定制功能。参见 Trusted Header SSO。这些响应头由 Authelia 在授权通过时写入。在 handler_authz_common.go 的handleAuthzAuthorizedStandard中可以看到响应 200 的同时会设置Remote-User用户名、Remote-Groups逗号分隔的组列表、Remote-Name显示名与Remote-Email邮箱头名常量定义在 const.go。测试用例 handler_authz_test.go 也验证了这些头会被正确回写。服务账号与普通用户同库、以组标识身份服务账号在 Authelia 用户库中配置方式与普通用户一致只是通过特定组来标识其身份。关键差异点组Groups同时包含myapp用于应用访问和service用于标识服务账号身份邮箱Email应使用监控/收件群组邮箱而非个人邮箱密码Password使用强度高、随机生成的密码64 字符因为它在程序化场景下使用不受多因素认证保护。人类用户如john只属于myapp组不含service因此会适用不同的认证要求users: my-service-account: displayname: My Service Account password: $argon2id$v19$m65536,t3,p2$BpLnfgDsc2WD8F2q$o/vzA4myCqZZ36bUGsDY//8mKUYNZZaR0t4MFFSsiM # digest for password email: my-service-accountexample.com groups: - myapp - service john: displayname: John Doe password: $argon2id$v19$m65536,t3,p2$BpLnfgDsc2WD8F2q$o/vzA4myCqZZ36bUGsDY//8mKUYNZZaR0t4MFFSsiM # digest for password email: john.doeauthelia.com groups: - myapp提示上面的密码哈希对应明文password仅作示例。生产环境请务必为服务账号生成独立、随机的强密码并使用 Authelia 提供的密码哈希生成工具。Authelia 访问控制规则按组成员资格分流认证强度以下 ACL 规则基于组成员资格建立不同的认证要求第一条规则同时拥有myapp与service组的用户即服务账号只需单因素认证one_factor这使 Basic Auth 能够正常工作第二条规则仅拥有myapp组的用户人类用户需要双因素认证two_factor强制他们通过 Web 界面完成第二因素。规则顺序至关重要。Authelia 对规则匹配有两个重要概念顺序匹配Sequential Order规则从上到下依次求值第一条完全匹配的规则生效。因此更具体的规则如服务账号的one_factor必须放在前面主体条件需要先完成认证Subject Criteria Requires Authentication在用户完成认证之前Authelia 无法得知其用户名与组。所以如果认证不满足规则就无法命中对应的subject。access_control: default_policy: deny rules: - domain: - myapp.example.com policy: one_factor subject: - [group:myapp, group:service] - domain: - myapp.example.com policy: two_factor subject: - group:myapp注意第一条规则的subject是嵌套列表[group:myapp, group:service]表示同时满足两个组条件这与普通列表满足其一即可的语义不同。借助该写法只有同时属于两个组的服务账号才会命中one_factor分支而普通用户落到第二条two_factor规则。这与 access-control.md 文档中关于规则求值顺序与主体条件的说明一致你还可以用authelia access-control check-policy命令验证某条请求到底命中哪条规则见 CLI 参考。被保护的应用零改造接入被保护应用即你的后端应用——API 服务器、Web 应用或任何需要保护的服务它不需要任何修改所有认证逻辑由 Authelia 处理应用只会在请求通过校验后才收到请求。如果应用需要知道访问者是谁可以读取 Authelia 透传的头如Remote-User、Remote-Groups来实现按用户定制或日志记录。这些头正是通过上文 Traefik 中间件的authResponseHeaders透传的。工作流程人类用户通过浏览器访问myapp.example.com被重定向到 Authelia 门户必须完成双因素认证才能获得访问权服务账号携带Authorization: Basic base64(username:password)头提交凭证即可绕过 Web 界面两种访问方式都由 Authelia 校验但根据组成员资格应用不同的 ACL 规则认证通过后请求带着额外的响应头转发到后端应用。从实现层面看Basic Auth 的校验发生在 Authelia 的认证策略中在 handler_authz_authn.go 中Authorization头按 scheme 分流Basicscheme 走handleGetBasic校验用户名密码并取得用户详情与认证级别Bearer则走 OIDC 流程。one_factor策略下 Basic Auth 即可满足认证级别这正是服务账号能用 Basic Auth 直连的原因而人类用户被two_factor规则强制走完整双因素流程。Basic Auth 的缓存与防爆破值得补充的是Authelia 对 Basic Auth 凭证校验做了性能与安全设计见 handler_authz_authn.go默认直接调用用户提供方如文件用户库或 LDAP的CheckUserPassword校验用户名与密码当配置了 Basic Auth 缓存存活期basic_auth_cache时会启用基于 HMAC-SHA256 的凭证缓存减少高频率程序化访问对认证后端的压力配合认证延迟timing attack delay机制可缓解针对 Basic Auth 的时序侧信道与暴力破解风险。验证浏览器访问验证在浏览器中打开https://myapp.example.com应被重定向到 Authelia以 John或其他用户身份登录并完成双因素认证应被重定向回你的应用。API 访问验证curl -u my-service-account:password https://myapp.example.com/-u参数会让 curl 自动构造Authorization: Basic base64(my-service-account:password)头。请求命中第一条 ACL 规则仅需单因素认证因此无需任何交互即可通过而后端应用会从Remote-User头读到my-service-account。常见用例监控与健康检查Uptime Kuma 等应用支持主动推送式健康检查应用周期性发送 API 请求上报当前状态。如果 Uptime Kuma 位于 Authelia 之后且认证已禁用你可以用服务账号放行这些推送 API 请求。若只想放行特定路径参见下文 路径级放行。日志与指标上报Loki、Mimir、Tempo 等日志/指标/追踪聚合器往往不自带认证本方案非常契合给采集 Agent 配置 Basic Auth 凭证即可向受保护的应用安全上报日志或指标。高级配置路径级放行Path Bypass如果只想对服务账号放行部分 API 路径而非整个 API可以借助访问控制的 resources 条件实现。下面的示例只允许myapp服务账号访问myapp.example.com/api/push/*而不允许其访问 myapp API 的其他部分access_control: default_policy: deny rules: - domain: - myapp.example.com policy: one_factor resources: - ^/api/push([/?].*)?$ subject: - [group:myapp, group:service]resources使用正则表达式匹配请求路径注意 Authelia 的正则区分大小写。将这条规则放在最前面使其先于其他更宽泛的规则被命中。关于resources的详细语义与示例参见 access-control.md 的 resources 小节。基于网络的访问控制你还可以通过访问控制中的networks选项限制服务账号允许使用的来源 IP 地址。例如仅允许监控探活主机或 CI 出口 IP 使用该服务账号从而显著缩小凭证泄露后的影响面。详见 access-control.md 的 networks 小节该选项支持 IP 地址、CIDR 网段以及网络别名alias的组合。安全注意事项实现 Authelia 服务账号时应牢记以下安全实践尽可能使用默认拒绝default deny策略确保服务账号只能访问被显式授权的资源只授予服务账号完成任务所需的最小权限由于服务账号绕过了多因素认证密码强度至关重要服务账号密码应至少 64 字符且随机生成避免在多个位置复用同一个服务账号应为不同场景分别建立服务账号这样既能精确定位被泄露的账号/机器也避免一次性在大量地方轮换凭证尽可能限制服务账号可用的来源 IP 地址利用networks条件定期审查在用服务账号及时清理不再使用的账号。小结本文围绕ForwardAuth 统一认证 服务账号 Basic Auth 程序化访问这一模式完整覆盖了 Traefik 中间件配置、服务账号用户库配置、按组分流的两级 ACL 规则、验证方法、监控/日志等典型用例、路径级与网络级的高级控制以及配套的安全实践。这套方案的价值在于后端应用零改造即可获得人走双因素门户、机走单因素 Basic Auth的差异化接入能力且认证决策全部集中在 Authelia 一处便于审计与治理。【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考