ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

Nginx UI 集成 Casdoor:OAuth 2.0 统一身份认证接入指南

Nginx UI 集成 Casdoor:OAuth 2.0 统一身份认证接入指南 Nginx UI 集成 CasdoorOAuth 2.0 统一身份认证接入指南【免费下载链接】nginx-uiYet another WebUI for Nginx项目地址: https://gitcode.com/gh_mirrors/ngi/nginx-ui本篇技术指南围绕 Nginx UI 的 Casdoor 认证提供方配置展开完整讲解Endpoint、ExternalUrl、ClientId、ClientSecret、CertificatePath、Organization、Application、RedirectUri八个配置项的含义与作用并结合源码梳理从「生成授权跳转地址」到「OAuth 回调换发登录令牌」的完整认证链路。读者完成后可以在自建 Casdoor 服务与 Nginx UI 之间搭建一套基于 OAuth 2.0 授权码模式的统一身份认证方案。Casdoor 认证接入概述Casdoor 是一套功能全面的身份认证IdP解决方案支持 OAuth 2.0、SAML 2.0、LDAP、AD 以及多种社交账号登录方式。Nginx UI 通过集成 Casdoor该集成由社区贡献者 Jraaay 提供可以将上述认证能力直接复用到 WebUI 的登录环节从而提升安全性与用户体验——例如由企业已有的 Casdoor 组织统一管理账号、统一颁发令牌Nginx UI 不再自行承担完整的身份源建设。从源码结构看Casdoor 接入主要由三部分构成配置模型settings/casdoor.go 定义了全部八个配置字段认证逻辑api/user/casdoor.go 实现了授权地址生成与回调换发令牌路由注册api/user/router.go 注册了GET /casdoor_uri与POST /casdoor_callback两个接口。整个流程基于 OAuth 2.0 授权码模式Authorization Code前端先向后端申请一个授权跳转地址用户跳转到 Casdoor 完成登录Casdoor 携带授权码回跳后端再用授权码换取访问令牌并解析用户身份。配置前提在 Nginx UI 中启用 Casdoor 之前需要先在 Casdoor 侧完成以下准备工作准备一份可信的证书Nginx UI 需要读取 Casdoor 用于签发 JWT 的公钥证书文件用于校验回调中携带的令牌签名证书路径通过CertificatePath指定该证书必须有效且受信任。在 Casdoor 中创建应用Application获取该应用对应的ClientId与ClientSecret并记录应用所属的Organization名称。约定回跳地址Redirect URI该地址必须与 Nginx UI 配置的RedirectUri完全一致否则 Casdoor 会拒绝回跳。值得强调的是回调校验环节的完整配置项是七个ExternalUrl之外的全部字段GetCasdoorUri仅要求Endpoint、ClientId、RedirectUri、Application四个字段非空即可生成授权地址而CasdoorCallback在Endpoint、ClientId、ClientSecret、CertificatePath、Organization、Application任一为空时会直接返回Casdoor is not configured错误见 api/user/casdoor.go。因此实际启用时应将八个配置项全部配置完整。配置项详解以下八个配置项与 Nginx UI 中[casdoor]配置节一一对应下面逐一说明其作用、类型与注意事项。Endpoint类型string环境变量NGINX_UI_CASDOOR_ENDPOINTCasdoor 服务的访问地址Base URL。Nginx UI 必须能够通过网络访问该 URL因为它既要用于生成授权跳转地址也会作为回调阶段 SDK 初始化时的服务端地址。从源码看GetCasdoorUri生成的授权地址形如{endpoint}/login/oauth/authorize?client_id{clientId}response_typecoderedirect_uri{encodedRedirectUri}state{state}scopereadExternalUrl类型string适用版本 v2.0.0-beta.42Casdoor 服务的外部访问地址External URL专门用于生成回调重定向 URI。当 Nginx UI 所在网络与用户浏览器访问 Casdoor 的路径不一致时例如 Nginx UI 服务端通过内网访问 Casdoor而浏览器需要走公网域名可通过该字段指定浏览器实际可达的地址。源码中的实现逻辑如下对应 GitHub issue #603 的需求当ExternalUrl非空时授权地址生成阶段会用它覆盖Endpoint作为 base URL未配置时则回退使用Endpointendpoint : settings.CasdoorSettings.Endpoint // feature request #603 if settings.CasdoorSettings.ExternalUrl ! { endpoint settings.CasdoorSettings.ExternalUrl }ClientId类型string环境变量NGINX_UI_CASDOOR_CLIENT_IDCasdoor 为你的应用生成的 Client ID用于在认证过程中标识 Nginx UI 这个 OAuth 客户端会以client_id参数的形式出现在授权跳转地址中。ClientSecret类型string环境变量NGINX_UI_CASDOOR_CLIENT_SECRETCasdoor 为你的应用生成的 Client Secret属于敏感凭据。在 settings/casdoor.go 中该字段被同时标记为protected:true与sensitive:true即接口返回时既受保护不暴露明文、也会被脱敏处理。请务必妥善保管避免泄露。CertificatePath类型string环境变量NGINX_UI_CASDOOR_CERTIFICATE_PATH认证过程中用于校验令牌的证书文件路径即 Casdoor 应用的公钥证书。回调处理时Nginx UI 会通过os.ReadFile(certificatePath)读取证书内容并交给 Casdoor SDK 初始化配置用于解析回调令牌。必须确保该路径存在、证书有效且受信任否则回调阶段会报错。Organization类型string环境变量NGINX_UI_CASDOOR_ORGANIZATION你在 Casdoor 中设置的组织Organization名称。SDK 初始化及认证请求处理都会使用该信息用于限定用户所属组织。Application类型string环境变量NGINX_UI_CASDOOR_APPLICATION你在 Casdoor 中创建的应用Application名称。RedirectUri类型string环境变量NGINX_UI_CASDOOR_REDIRECT_URI用户登录/授权成功后将被重定向到的 URI。该值必须与 Casdoor 应用配置中的 Redirect URI 保持一致并且在授权地址中以 URL 编码url.QueryEscape形式作为redirect_uri参数传递。配置文件写法在 Nginx UI 的配置文件app.ini配置说明见 docs/guide/config-app.md中新增[casdoor]配置节并逐项填写[casdoor] Endpoint https://casdoor.example.com ExternalUrl https://casdoor.example.com ClientId your-client-id ClientSecret your-client-secret CertificatePath ./casdoor.pub Organization your-org Application nginx-ui-app RedirectUri https://nginx-ui.example.com/api/user/casdoor_callback需要说明的是RedirectUri并不要求必须指向 Nginx UI 自身——它可以是任何前端页面地址回调数据由前端通过 POST 提交给/api/user/casdoor_callback完成最终换发。但若希望全程由 Nginx UI 后端处理回跳可以按上述方式配置。环境变量方式除了配置文件还可以通过环境变量注入配置。Nginx UI 在 settings/settings.go 中将CASDOOR前缀映射到CasdoorSettings并在 docs/guide/env.md 中给出了完整的变量对照表配置项环境变量EndpointNGINX_UI_CASDOOR_ENDPOINTClientIdNGINX_UI_CASDOOR_CLIENT_IDClientSecretNGINX_UI_CASDOOR_CLIENT_SECRETCertificatePathNGINX_UI_CASDOOR_CERTIFICATE_PATHOrganizationNGINX_UI_CASDOOR_ORGANIZATIONApplicationNGINX_UI_CASDOOR_APPLICATIONRedirectUriNGINX_UI_CASDOOR_REDIRECT_URI该环境变量映射行为同样有单元测试覆盖见 settings/settings_test.go例如设置NGINX_UI_CASDOOR_CLIENT_SECRETclientSecret后CasdoorSettings.ClientSecret会被正确解析。此外 settings/server_v1_test.go 还展示了[casdoor]节在 v1 配置格式下的示例。认证流程与源码级解析配置完成后一次完整的 Casdoor 登录包含两个后端接口下面结合 api/user/casdoor.go 逐段拆解。第一步申请授权跳转地址GET /casdoor_uri前端调用GET /api/user/casdoor_uri路由见 api/user/router.go后端GetCasdoorUri完成如下工作读取Endpoint若有ExternalUrl则覆盖、ClientId、RedirectUri、Application任一为空则返回{uri: }生成 16 字节加密随机数构造state值nginx-ui-casdoor_ hex 编码随机串将state写入名为casdoor_state的 Cookie有效期 300 秒HttpOnly、Secure、SameSiteLax见setCasdoorStateCookie用于后续回调校验返回完整的授权地址{endpoint}/login/oauth/authorize?...state{state}scoperead。单元测试 api/user/casdoor_test.go 中的TestGetCasdoorUriSetsRandomStateCookie验证了返回的state以nginx-ui-casdoor_前缀开头、与 Cookie 值一致、Cookie 设置了MaxAge300且具备HttpOnly、Secure、SameSiteLax属性。第二步用户跳转 Casdoor 并回跳浏览器跳转到授权地址用户在 Casdoor 完成登录后Casdoor 携带code与state重定向到RedirectUri指向的页面。前端拿到这两个参数后调用POST /api/user/casdoor_callback提交。第三步回调校验并换发令牌POST /casdoor_callbackCasdoorCallback的处理顺序如下参数绑定校验请求体必须包含code与statebinding:required,max255state 校验比对请求中的state与 Cookie 中的casdoor_state。这里采用 SHA-256 摘要后subtle.ConstantTimeCompare常量时间比较constantTimeStateEqual以降低时序侧信道风险不匹配则返回 403State mismatch。校验通过后立即清除 CookieMax-Age0防止重放。对应测试TestCasdoorCallbackRejectsStateMismatchBeforeExchange与TestValidateCasdoorStateClearsCookieOnMatch均覆盖了这些安全行为配置完整性检查读取Endpoint、ClientId、ClientSecret、CertificatePath、Organization、Application任一为空返回 500Casdoor is not configured读取证书os.ReadFile(certificatePath)读取证书内容SDK 初始化与换码以证书内容调用casdoorsdk.InitConfig(...)再用casdoorsdk.GetOAuthToken(code, state)向 Casdoor 换取访问令牌解析身份casdoorsdk.ParseJwtToken(token.AccessToken)解析 JWT取出claims.Name作为用户名关联本地用户调用user.GetUser(claims.Name)在 Nginx UI 本地用户表中查找对应用户。若不存在gorm.ErrRecordNotFound返回 403User not exist——这意味着 Casdoor 中的账号必须先在 Nginx UI 中以相同用户名创建才能完成登录这是一个容易被忽略的实操要点换发登录令牌调用user.IssueLoginToken(u, user.LoginProofExternal)签发 Nginx UI 自身的 JWT登录证明类型为external见 internal/user/user.go随后通过middleware.EnsureSecureSessionCookie确保会话 Cookie 安全最终返回与密码登录一致的LoginResponse。从源码可以推断LoginProofExternal走的是「外部身份源认证」通道由于是外部 IdP 已经完成身份验证该路径不会触发 OTP/Passkey 二次验证逻辑只有LoginProofPassword路径才会检查EnabledOTP与EnabledPasskey。安全注意事项State 防 CSRF授权请求阶段生成的随机state会写入HttpOnly、Secure、SameSiteLaxCookie并在回调阶段做常量时间比较后即销毁可有效防止跨站请求伪造与授权码重放Secret 保护ClientSecret在配置结构中标记为sensitive接口返回配置时会脱敏请勿将其写入前端代码或日志证书可信CertificatePath指向的证书用于校验 Casdoor 签发的 JWT务必使用可信渠道获取并定期更新避免令牌校验失效或信任被篡改的证书账号映射Casdoor 用户必须预先存在于 Nginx UI 用户表中登录才会成功建议为外部认证用户建立清晰的账号命名约定便于审计与权限管理HTTPS 环境回调写入 Cookie 时受EnableHTTPS开关控制Secure标志生产环境请确保通过 HTTPS 提供服务。验证与排障授权地址是否生成访问GET /api/user/casdoor_uri若返回{uri: }说明Endpoint/ClientId/RedirectUri/Application存在缺失需回到 docs/guide/config-app.md 检查配置回跳是否可达确认 Nginx UI 与浏览器都能访问Endpoint或ExternalUrl且RedirectUri与 Casdoor 应用配置完全一致回调报错定位Casdoor is not configured表示回调所需配置项缺失State mismatch表示 state 校验失败可能是 Cookie 丢失、跨域或重放User not exist表示 Casdoor 账号未在 Nginx UI 中创建证书问题CertificatePath读取失败或证书不受信任时回调阶段会在os.ReadFile或 SDK 初始化处报错请核对路径与证书格式PEM自动化验证仓库自带的 api/user/casdoor_test.go 是理解预期行为的参考——它验证了 state Cookie 的随机性、安全属性、state 不匹配时的 403 拒绝以及校验通过后的 Cookie 清理可用于对照排查自定义部署中的异常表现。总结Nginx UI 的 Casdoor 集成将企业级身份源能力与轻量 WebUI 管理面打通在 Casdoor 侧创建应用并准备证书在 Nginx UI 侧完整配置[casdoor]节八个字段即可获得基于 OAuth 2.0 授权码模式的统一登录。整个接入过程的关键在于配置完整、Redirect URI 一致、本地用户预先存在三点配合源码级的状态校验与令牌换发机制既保证了接入的开放性也维持了认证链路的安全性。【免费下载链接】nginx-uiYet another WebUI for Nginx项目地址: https://gitcode.com/gh_mirrors/ngi/nginx-ui创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表