oauth2-proxy 接入 SourceHutOAuth 2.0 认证配置与自托管实例对接实战【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxySourceHut 是 oauth2-proxy 内置支持的身份提供者之一。本文围绕 version-7.14.x 的 SourceHut 配置文档 展开完整讲解如何在 meta.sr.ht 上创建 OAuth 客户端、如何用--providersourcehut启动 oauth2-proxy以及自托管 SourceHut 实例下的四个端点参数配置并深入源码说明登录、令牌兑换、用户信息拉取与会话校验的底层实现最终给出基于 email 的访问控制方案。读完本文你将能够独立完成 SourceHut 与 oauth2-proxy 的对接并针对自托管环境做正确部署。前置条件在 meta.sr.ht 创建 OAuth 客户端使用 SourceHut 作为认证源的第一步是在 SourceHut 的账户系统meta.sr.ht上注册一个 OAuth 应用打开 OAuth 客户端创建页面https://meta.sr.ht/oauth2 创建一个新的 OAuth client在Redirection URI重定向 URI一栏填写 oauth2-proxy 的回调地址格式为 oauth2-proxy 对外暴露的 HTTPS 地址加上/oauth2/callback路径例如https://internal.yourcompany.com/oauth2/callback这个回调地址必须与 oauth2-proxy 启动参数--redirect-url保持一致oauth2-proxy 完成授权码交换时会回调到该地址。若 oauth2-proxy 前面还套了反代或域名映射请务必填写最终用户浏览器可访问的公网地址。启用 SourceHut Provider 并启动 oauth2-proxyoauth2-proxy 内置了 SourceHut 提供者无需额外插件。在启动参数中加入--providersourcehut即可启用--providersourcehut配合客户端凭据和回调地址一个最小可运行的命令行如下客户端 ID、密钥请替换为你在 meta.sr.ht 创建应用时获得的值oauth2-proxy \ --providersourcehut \ --client-idyour-client-id \ --client-secretyour-client-secret \ --redirect-urlhttps://internal.yourcompany.com/oauth2/callback \ --upstreamhttp://127.0.0.1:8080从源码看provider 的注册位于 providers/providers.go 的NewProvider工厂函数中当配置的 provider 类型为SourceHutProvider时直接调用NewSourceHutProvider(providerData)构建实例同时providerRequiresOIDCProviderVerifierproviders/providers.go将 SourceHut 归入不需要 OIDC 校验器的一类即该 provider 不走 OpenID Connect 发现机制全部依赖下面将要说明的四个固定端点完成 OAuth 2.0 流程。默认端点与 Scopeproviders/srht.go 中定义了 SourceHut 提供的默认值与默认端点默认 Scopemeta.sr.ht/PROFILE:RO即只读访问用户资料默认登录授权端点https://meta.sr.ht/oauth2/authorize默认令牌兑换端点https://meta.sr.ht/oauth2/access-token默认用户资料GraphQL端点https://meta.sr.ht/query默认会话校验端点https://meta.sr.ht/profile。这些默认值由NewSourceHutProviderproviders/srht.go通过setProviderDefaults写入ProviderData。只要配置里没有显式覆盖oauth2-proxy 就会使用这些公共云服务地址。自托管 SourceHut 实例覆盖四个端点参数如果你们自行部署了 SourceHut 实例上述默认端点均指向公共的meta.sr.ht无法满足内网或隔离环境的需求。此时必须在启动参数中显式指定以下四个 URL将其中的meta.your.instance替换为你们自建 SourceHut 元服务meta service的实际地址--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四个参数的作用如下参数对应阶段说明--login-url发起登录构造授权页跳转链接用户在此完成 SourceHut 账号登录与授权--redeem-url回调换令牌用授权码code向该地址换取access_token--profile-url拉取用户信息SourceHut 的 GraphQL 查询端点用于获取 email 与 username--validate-url会话校验校验access_token是否仍然有效这四个 URL 在 providers/provider_data.go 中统一解析为*url.URL解析失败会聚合报错。覆盖机制依赖defaultURLproviders/provider_data.go只有配置为空时才回落到内置默认值因此你可以只覆盖需要的端点其余保持默认。完整自托管启动示例oauth2-proxy \ --providersourcehut \ --client-idyour-client-id \ --client-secretyour-client-secret \ --redirect-urlhttps://internal.yourcompany.com/oauth2/callback \ --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 \ --upstreamhttp://127.0.0.1:8080源码视角登录、换令牌与用户信息填充登录 URL 的构造发起登录时oauth2-proxy 会基于LoginURL拼装授权请求。makeLoginURLproviders/util.go在授权链接上附带redirect_uri、scope默认即meta.sr.ht/PROFILE:RO、client_id、response_typecode以及防 CSRF 的state参数用户授权后浏览器携带code重定向回回调地址。用户信息拉取GraphQL 查询SourceHut 的用户信息端点不是标准的 userinfo REST 接口而是 GraphQL 端点/query。providers/srht.go 的EnrichSession展示了 oauth2-proxy 是如何调用它的请求方法为POST请求头携带Content-Type: application/json请求头携带Authorization: Bearer access_token请求体为 GraphQL 查询语句{query: { me { username, email } }}从响应data.me.email提取邮箱填充会话的Email字段从响应data.me.username提取用户名填充会话的PreferredUsername与User字段。这说明 oauth2-proxy 将 SourceHut 的 GraphQL 端点当作用户信息端点使用登录完成后即可在会话中获得用户的邮箱与用户名供后续日志、请求头注入和访问控制使用。会话校验令牌有效性探测ValidateSessionproviders/srht.go在每次会话复用时被调用用于确认access_token仍然有效。其底层是通用函数validateTokenproviders/internal_util.go向ValidateURL即/profile发起带认证头的请求HTTP 200 即视为令牌有效令牌为空或校验端点未配置时直接返回无效。认证头由makeOIDCHeaderproviders/util.go生成采用Bearer前缀并附带Accept: application/json。测试用例验证providers/srht_test.go 中的TestSourceHutProvider_ValidateSessionWithUserEmails通过 mock 后端同时返回/query的 GraphQL 响应{data:{me:{username:bitfehler,email:chbitfehler.net}}}与/profile的ok验证了用户信息可获取 令牌有效的完整链路判定为合法会话而TestSourceHutProvider_ValidateSessionWithBaseUrl则在无任何响应时判定会话无效。这为对接排障提供了参照若登录后立即被登出可重点检查ValidateURL是否可达、access_token是否被 SourceHut 侧吊销。访问控制默认放行与基于 Email 的限制需要特别留意的是SourceHut provider 的默认策略是允许所有拥有 SourceHut 账号的用户通过认证并不检查他们属于哪个组织或仓库。当前版本下对 SourceHut 用户做精细化限制只能通过 email 认证实现具体做法与 Email Authentication 通用说明 一致可选以下三种方式# 方式一只允许指定邮箱域名的用户 --email-domainyourcompany.com # 方式二通过文件列出允许的邮箱地址每行一个 --authenticated-emails-file/path/to/file # 方式三允许所有邮箱地址注意这会放开默认限制 --email-domain*# /path/to/file 示例内容 aliceyourcompany.com bobyourcompany.com示例仅允许公司域名用户登录的自托管部署oauth2-proxy \ --providersourcehut \ --client-idyour-client-id \ --client-secretyour-client-secret \ --redirect-urlhttps://internal.yourcompany.com/oauth2/callback \ --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 \ --email-domainyourcompany.com \ --upstreamhttp://127.0.0.1:8080注意email 过滤依赖EnrichSession从 GraphQL 端点取回的email字段因此在自托管环境中务必保证--profile-url指向正确的/query端点否则 email 为空将导致基于 email 的授权规则无法命中。小结与排障提示对接 SourceHut provider 的关键点可归纳为四点一是回调地址必须与--redirect-url一致二是公共云场景直接使用--providersourcehut即可自托管场景必须覆盖--login-url、--redeem-url、--profile-url、--validate-url四个端点三是用户信息来自/queryGraphQL 端点会话有效性依赖/profile端点返回 200四是默认策略放行全部账号如需限制必须启用 email 认证。若出现登录成功但随即失效的现象建议先检查--validate-url指向的/profile端点是否被自托管实例正确暴露并对照 providers/srht_test.go 中的 mock 响应格式排查返回内容。【免费下载链接】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），仅供参考