oauth2-proxy 集成 SourceHut 身份提供商配置、自托管 URL 定制与源码级认证流程解析【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxy本文以 oauth2-proxy 的 SourceHut provider 为核心讲解如何注册 SourceHut OAuth 应用、通过--providersourcehut启用认证、针对自托管 SourceHut 实例定制登录/令牌/资料/校验端点并结合仓库源码剖析会话丰富EnrichSession与令牌校验ValidateSession的底层实现。读完本文你将能够独立完成 oauth2-proxy 与 SourceHut公有云或自托管实例的对接并理解其认证请求的真实调用链与测试验证方法。SourceHut provider 在 oauth2-proxy 中的定位SourceHutsr.ht是一套面向开发者的开源托管平台提供基于 OAuth 2.0 的第三方应用授权。oauth2-proxy 将其实现为内置认证提供商之一定义于 providers/srht.goSourceHutProvider结构体内嵌*ProviderData并通过var _ Provider (*SourceHutProvider)(nil)在编译期强制保证其完整实现了Provider接口提供商名称为SourceHut默认请求的 OAuth scope 为meta.sr.ht/PROFILE:RO只读读取用户元资料权限。在 providers/providers.go 中provider 工厂函数New()通过case options.SourceHutProvider: return NewSourceHutProvider(providerData), nil完成注册因此只需在启动参数中指定--providersourcehut即可激活。此外providers/providers.go 的providerRequiresOIDCProviderVerifier表明 SourceHut 与 GitHub、Google 等一样不依赖 OIDC 发现协议走的是传统 OAuth 2.0 授权码流程这也是下文四个自定义 URL 参数发挥作用的原因。第一步在 SourceHut 创建 OAuth 客户端要使用 SourceHut 作为认证源首先需要在其元服务meta.sr.ht上注册一个 OAuth 客户端打开https://meta.sr.ht/oauth2创建新的 OAuth client在Redirection URI回调地址中填写 oauth2-proxy 实际的回调 URL例如https://internal.yourcompany.com/oauth2/callback回调路径必须与 oauth2-proxy 默认回调端点/oauth2/callback完全一致同时域名部分要与实际对外暴露的地址匹配注册完成后会得到client_id与client_secret分别通过--client-id与--client-secret传入 oauth2-proxy。第二步启用 provider 并传递凭证注册完成后使用如下命令行参数启动 oauth2-proxyoauth2-proxy \ --providersourcehut \ --client-idyour-client-id \ --client-secretyour-client-secret \ --email-domainyourcompany.com \ --http-address0.0.0.0:4180 \ --upstreamhttp://127.0.0.1:8080其中--providersourcehut是激活该 provider 的唯一入口大小写不敏感地映射到options.SourceHutProvider。从源码看providers/srht.go 中NewSourceHutProvider调用p.setProviderDefaults会为登录、换令牌、资料、校验四个端点注入面向公有云 meta.sr.ht 的默认 URL配置项默认值公有云用途--login-urlhttps://meta.sr.ht/oauth2/authorizeOAuth 授权入口重定向用户去授权--redeem-urlhttps://meta.sr.ht/oauth2/access-token用授权码换取 access token--profile-urlhttps://meta.sr.ht/queryGraphQL 查询端点用于拉取用户资料--validate-urlhttps://meta.sr.ht/profile校验 access token 是否仍然有效这些默认 URL 以预解析的*url.URL形式硬编码在 providers/srht.go 中只有当你自行托管 SourceHut 实例时才需要覆盖。第三步自托管 SourceHut 实例的 URL 定制如果你部署的是自己的 SourceHut 实例而非使用官方托管服务必须将上述四个端点显式指向自建域名否则认证会落到meta.sr.ht导致跨实例认证失败--login-urlhttps://meta.your.instance/oauth2/authorize --redeem-urlhttps://meta.your.instance/oauth2/access-token --profile-urlhttps://meta.your.instance/query --validate-urlhttps://meta.your.instance/profile这组参数定义于 pkg/apis/options/legacy_options.go对应LoginURL、RedeemURL、ProfileURL、ValidateURL四个字段同时支持命令行 flaglogin-url等与配置文件字段login_url等两种方式。在 pkg/apis/options/legacy_options.go 中可以看到它们被统一映射进Provider结构体最终由NewSourceHutProvider通过setProviderDefaults合并进ProviderData——用户在命令行显式传入的 URL 会覆盖源码中的默认值而未指定的项则保持默认。提示四个 URL 中--profile-url指向 SourceHut 的 GraphQL 端点/query--validate-url指向/profile两者职责不同不能混填这从 providers/srht.go 与validateToken的调用方式中可以明确看出。源码级解析会话如何被丰富与校验EnrichSession通过 GraphQL 拉取邮箱与用户名当用户完成授权、oauth2-proxy 拿到 access token 后providers/srht.go 的EnrichSession会向--profile-url发送一次POST请求requests.New(p.ProfileURL.String()). WithContext(ctx). WithMethod(http.MethodPost). SetHeader(Content-Type, application/json). SetHeader(Authorization, Bearer s.AccessToken). WithBody(bytes.NewBufferString({query: { me { username, email } }})). Do(). UnmarshalSimpleJSON()关键点请求以Bearer token方式携带 access tokenAuthorization: Bearer ...请求体是 GraphQL 查询{ me { username, email } }响应解析后通过json.GetPath(data, me, email)提取邮箱写入s.Email通过json.GetPath(data, me, username)提取用户名分别写入s.PreferredUsername与s.User若响应缺少对应字段会返回unable to extract email/userinfo from userinfo endpoint类错误该会话将视为不完整。这与文档 docs/versioned_docs/version-7.11.x/configuration/providers/index.md 中并非所有 provider 都支持全部 claims的说明一致SourceHut 通过 profile 端点补齐了email与preferred_username。ValidateSession令牌有效性校验每个已建立会话在请求到达受保护后端前都会经过 providers/srht.go 的ValidateSession其核心是调用通用工具函数validateTokenfunc (p *SourceHutProvider) ValidateSession(ctx context.Context, s *sessions.SessionState) bool { return validateToken(ctx, p, s.AccessToken, makeOIDCHeader(s.AccessToken)) }validateToken实现在 providers/internal_util.go行为如下若 access token 为空或--validate-url未配置直接返回false向ValidateURL发起 GET 请求携带makeOIDCHeader构造的Authorization: Bearer token头见 providers/util.go同时附带Accept: application/json等 IDP 必需头仅在响应状态码为200时判定令牌有效其余状态码或请求错误一律视为失效并记录脱敏后的日志access_token 参数会被截断隐藏见 providers/internal_util.go 的stripToken。也就是说SourceHut 的会话校验不依赖本地解析 ID token而是每次会话访问都向后端/profile端点发起一次实时校验请求这既是强一致性的体现也意味着会话期间 SourceHut 需要保持可达。访问控制默认放开、按邮箱收窄需要特别强调的是默认配置下任何拥有 SourceHut 账号的用户都能通过认证。文档 docs/versioned_docs/version-7.11.x/configuration/providers/sourcehut.md 明确说明目前 SourceHut provider 的访问限制仅支持通过邮箱维度收窄不支持按组织/团队等维度过滤。实现收窄的两种方式详见 docs/versioned_docs/version-7.11.x/configuration/providers/index.md限定邮箱域名--email-domainyourcompany.com仅允许该域名下邮箱的用户通过精确邮箱白名单--authenticated-emails-file/path/to/file文件内每行一个邮箱地址放开所有邮箱--email-domain*与默认行为等价一般无需显式设置。由于EnrichSession已确保会话中包含来自 SourceHut 的真实邮箱上述规则可以可靠地匹配生效。测试验证与可观测性仓库为 SourceHut provider 提供了完整的单元测试可作为自托管实例对接时的验证参考providers/srht_test.go 中用httptest.Server模拟后端分别覆盖TestSourceHutProvider_ValidateSessionWithBaseUrl后端未配置任何端点时令牌校验应返回falseTestSourceHutProvider_ValidateSessionWithUserEmails当/query返回{data:{me:{username:bitfehler,email:chbitfehler.net}}}、/profile返回ok时校验应返回true。这两个用例验证了validateToken对状态码的判定逻辑也间接确认了自托管实例只需保证/query与/profile两个端点按约定响应即可通过校验。快速核查清单完成对接后可按下表逐项自查检查项期望结果OAuth client 回调地址与--redirect-url/实际https://域/oauth2/callback一致--providersourcehut自托管实例四个 URL 均已指向自建域名访问控制已按需设置--email-domain或--authenticated-emails-file连通性实例能访问meta.sr.ht公有云或自建 meta 服务自托管若认证后跳转失败或会话反复失效优先检查--validate-url对应端点是否返回200以及--profile-url的 GraphQL 响应是否包含data.me.username/data.me.email字段——这两点正是 SourceHut provider 整个认证闭环中最关键的依赖。【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考