使用 Authelia OpenID Connect 1.0 为 Budibase 配置单点登录SSO【免费下载链接】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 作为 OpenID Connect 1.0 提供方OP与低代码应用平台 Budibase 对接实现基于 Authelia 的集中认证与双因素2FA登录。读完本文你将掌握在 Authelia 中注册 Budibase 客户端所需的完整 YAML 配置、Budibase 侧 Web GUI 的逐步设置方法以及该集成中涉及的关键协议细节与安全注意事项。测试版本与适用范围本集成示例在以下版本组合上验证通过来源集成文档Autheliav4.38.0Budibasev2.13.9需要注意的是文档标注该集成的支持级别为community社区级且versions与integration均标记为 true即上述版本组合经过验证但其他版本组合需要自行确认兼容性。Budibase 官方对 OpenID Connect 的支持文档可在其官方站点查阅见文末延伸阅读。前置假设本示例基于以下约定展开实际部署时请替换为你的域名与主机名项目值Budibase 应用根地址https://budibase.example.com/Authelia 根地址https://auth.example.com/Client IDbudibaseClient Secretinsecure_secret文档中的部分值支持通过文档站点变量自动替换如domain、subdomain-authelia下文统一以example.com与auth子域为例进行说明。提示阅读本指南前建议先通读 Authelia 的 OpenID Connect 1.0 客户端配置指南其中包含配置注册客户端前必须仔细考虑的重要元素。通用注意事项在动手配置前有几个来自 Authelia 官方集成文档的通用要点需要知晓内容源自 oidc-common 短代码模板client_id必须唯一每个客户端的client_id都必须是唯一值且只能包含 RFC3986 未保留字符长度不超过 100 字符。本文示例中的budibase仅为便于阅读和演示生产环境不应直接使用建议通过 Authelia 的随机生成能力生成 64 位随机字符。client_secret强烈建议以哈希形式存储示例中的insecure_secret仅是演示值。虽然明文存储当前仍被支持但该行为已被弃用不保证未来继续支持。以哈希形式存储时如果哈希工作因子work factor设置过高可能导致客户端请求超时详见调整工作因子相关 FAQ。配置示例并不完整下文给出的 Authelia YAML 片段只包含客户端注册部分你必须同时按 OpenID Connect 1.0 Provider 配置指南 完成 Provider 级必备配置同时该片段只覆盖了注册客户端众多可用选项中的一小部分建议完整阅读 OpenID Connect 1.0 客户端配置指南 以了解每个选项的作用与可选项。第一步在 Authelia 中注册 Budibase 客户端Authelia 的 OpenID Connect 1.0 提供方配置位于identity_providers.oidc之下。以下 YAML 是与上述应用示例配套的Authelia 客户端配置identity_providers: oidc: ## The other portions of the mandatory OpenID Connect 1.0 configuration go here. ## See: https://www.authelia.com/c/oidc clients: - client_id: budibase client_name: Budibase client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # The digest of insecure_secret. authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://budibase.example.com/api/global/auth/oidc/callback scopes: - openid - offline_access - profile - email response_types: - code grant_types: - authorization_code - refresh_token access_token_signed_response_alg: none userinfo_signed_response_alg: none token_endpoint_auth_method: client_secret_basic下面对每个关键字段逐一说明其作用与取值依据client_id / client_name / client_secretclient_idBudibase 在授权请求中使用的客户端标识取值budibase见配置文档。client_name客户端的展示名称仅在 Authelia 的管理界面等场景中用于标识取Budibase见配置文档。client_secret此处存放的是insecure_secret的PBKDF2-SHA512 摘要$pbkdf2-sha512$310000$...而非明文。这是 Authelia 强烈推荐的做法详见上文通用注意事项。authorization_policy取值为two_factor表示当 Budibase 用户发起授权时Authelia 将强制要求双因素认证。可选值还包括one_factor等详见授权策略配置。require_pkce / pkce_challenge_methodrequire_pkce: false当前不强制要求客户端使用 PKCEProof Key for Code Exchange。需要说明的是Authelia 对 PKCE 的支持属于其 OpenID Certified™ 认证套件的一部分原则上任何有能力执行S256变换的依赖方都应使用S256方法此处关闭是为了兼容 Budibase 的实现。pkce_challenge_method: 空字符串表示不限制挑战方法见配置文档。redirect_uris回调地址列表Budibase 完成 OIDC 认证后 Authelia 会将授权码重定向至此https://budibase.example.com/api/global/auth/oidc/callback该地址必须与 Budibase 侧展示的 Callback URL 完全一致见下文第二步。回调路径/api/global/auth/oidc/callback是 Budibase 内部处理 OIDC 回调的固定路径。scopes向 Authelia 请求的权限范围见配置文档openidOIDC 核心范围必选表示发起 OpenID Connect 认证请求。offline_access允许 Budibase 获取 Refresh Token用于在用户离线时刷新 Access Token 以维持会话。profile允许读取用户资料类声明如用户名、显示名等。email允许读取用户的电子邮件地址声明。response_types / grant_typesresponse_types: [code]只使用Authorization Code Flow授权码流程这是最安全、最标准的 Web 应用流程见响应类型说明。grant_types同时声明authorization_code授权码换取 Token与refresh_token刷新 Token两种授权类型后者需要配合前面的offline_access范围才能正常使用见授权类型说明。签名与端点认证access_token_signed_response_alg: noneAccess Token 不签名。从 Authelia 的默认实现看Access Token 默认是不透明opaque令牌而非 JWT详见 FAQ为什么 Access Token 不是 JWT因此这里显式声明none。userinfo_signed_response_alg: noneUserInfo 端点以普通 JSON 返回用户信息不做 JWT 签名见UserInfo 签名算法说明。token_endpoint_auth_method: client_secret_basicBudibase 在 Token 端点通过HTTP Basic AuthRFC 6749 定义的客户端认证方式携带 Client ID 与 Client Secret 进行认证见客户端认证方式说明。关于access_token_signed_response_alg: none还需要补充一点Authelia 的 OIDC 实现是OpenID Certified™的Basic OP / Implicit OP / Hybrid OP / Form Post OP / Config OP 五类 profile并支持none表示不签名/不加密。同时从 oidc-common 模板 可以看到集成第三方客户端时要注意客户端凭据编码类问题——client_secret_basic要求 Client ID 与 Client Secret 在使用前按 RFC6749 附录 B 进行 URL 转义因此务必避免在 Client ID/Secret 中使用特殊字符这正是示例选择纯小写字母数字值的原因。第二步在 Budibase 侧配置 OpenID ConnectBudibase 的 OIDC 配置只有一种方式Web GUI。无需自行编辑其服务端配置文件。可以跳过第 13 步直接访问以下 URL 进入组织设置https://budibase.example.com/builder/portal/settings/organisation配置组织信息通过以下任一方式进入组织设置页直接访问https://budibase.example.com/builder/portal/settings/organisation依次导航进入Builder 主页面→Settings设置→Organization组织。配置以下选项Org. name组织名称example.comPlatform URL平台地址https://budibase.example.com点击Save保存。如上图所示组织设置页位于 Budibase 的深色管理后台中标题为 Organisation除Org. name与Platform URL外还包含 Analytics 分析开关保存后这些信息将用于 Budibase 生成与 OIDC 相关的内部回调地址。配置 OpenID Connect 认证通过以下任一方式进入认证设置页直接访问https://budibase.example.com/builder/portal/settings/auth依次导航进入Builder 主页面→Settings设置→Auth认证→OpenID Connect。配置以下选项字段值Config URLhttps://auth.example.com/.well-known/openid-configurationClient IDbudibaseClient Secretinsecure_secretNameAutheliaIconauthelia.svg可从 Authelia 的品牌资源指南下载点击Save保存。关键字段解读Config URL即 Authelia 的 OpenID Connect Discovery 1.0 发现端点。Budibase 会拉取该地址返回的 JSON 元数据自动发现授权端点、Token 端点、UserInfo 端点、JWKS 等全部必要端点详见端点实现一览因此该 URL 必须指向 Authelia 根地址下的固定路径/.well-known/openid-configuration。Client ID / Client Secret必须与 Authelia 客户端配置中的client_id、以及client_secret对应的明文值保持一致——注意 Budibase 侧填写的是原始明文insecure_secret而 Authelia 配置文件里存储的是它的 PBKDF2 摘要两者通过摘要校验算法等价对应。Name / Icon用于自定义 Budibase 登录页上的 SSO 登录按钮文案与图标。从界面截图中还可以看到认证设置页包含Callback URL字段示例https://budibase.example.com/api/global/auth/oidc/callback与Auth Scopes字段默认值openid profile email offline_access前者与 Authelia 侧redirect_uris一一对应后者与 Authelia 侧scopes保持一致建议核对两者与 Authelia 配置中的值是否匹配。第三步验证集成完成上述两步配置后可通过以下方式验证集成是否生效访问 Budibase 登录页确认出现名为Authelia的 SSO 登录按钮点击该按钮浏览器应被重定向到 Authelia 的登录界面https://auth.example.com完成用户名/密码认证后若authorization_policy为two_factor还会继续要求第二因素如 TOTP、WebAuthn 等认证认证成功后浏览器应回跳到https://budibase.example.com/api/global/auth/oidc/callback随后自动登录 Budibase 后台。从实现层面看Budibase 属于使用授权码流程 Client Secret Basic 认证的标准机密客户端confidential client。整个登录链路对应 Authelia 的 授权码流程Budibase 先请求授权端点取得授权码再用client_secret_basic方式在 Token 端点换取 ID Token 与 Access Token最后通过 UserInfo 端点获取profile/email范围对应的用户声明。常见问题与排错建议登录按钮未出现或点击后报错优先检查 Budibase 的Config URL是否可访问直接在浏览器打开该地址应返回包含authorization_endpoint、token_endpoint等字段的 JSON 元数据。回调失败redirect_uri mismatchAuthelia 的redirect_uris与 Budibase 侧显示的 Callback URL 必须逐字符一致注意协议https、主机名、端口与路径/api/global/auth/oidc/callback都不能有差异。Token 交换失败确认 Budibase 侧填写的 Client Secret 明文与 Authelia 配置中摘要对应的原文一致同时确保 Client ID/Secret 中不含特殊字符参见通用注意事项中关于 RFC6749 附录 B 编码问题的说明。想开启更强校验可考虑将require_pkce设为true并指定pkce_challenge_method: S256前提是所用 Budibase 版本支持 PKCE。延伸阅读Budibase OpenID Connect 文档Budibase 官方文档Authelia OpenID Connect 1.0 集成总览Authelia OpenID Connect 1.0 客户端配置Authelia OpenID Connect 1.0 Provider 配置Authelia OIDC 常见问题FAQ【免费下载链接】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 OpenID Connect 1.0 为 Budibase 配置单点登录（SSO）
使用 Authelia OpenID Connect 1.0 为 Budibase 配置单点登录SSO【免费下载链接】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 作为 OpenID Connect 1.0 提供方OP与低代码应用平台 Budibase 对接实现基于 Authelia 的集中认证与双因素2FA登录。读完本文你将掌握在 Authelia 中注册 Budibase 客户端所需的完整 YAML 配置、Budibase 侧 Web GUI 的逐步设置方法以及该集成中涉及的关键协议细节与安全注意事项。测试版本与适用范围本集成示例在以下版本组合上验证通过来源集成文档Autheliav4.38.0Budibasev2.13.9需要注意的是文档标注该集成的支持级别为community社区级且versions与integration均标记为 true即上述版本组合经过验证但其他版本组合需要自行确认兼容性。Budibase 官方对 OpenID Connect 的支持文档可在其官方站点查阅见文末延伸阅读。前置假设本示例基于以下约定展开实际部署时请替换为你的域名与主机名项目值Budibase 应用根地址https://budibase.example.com/Authelia 根地址https://auth.example.com/Client IDbudibaseClient Secretinsecure_secret文档中的部分值支持通过文档站点变量自动替换如domain、subdomain-authelia下文统一以example.com与auth子域为例进行说明。提示阅读本指南前建议先通读 Authelia 的 OpenID Connect 1.0 客户端配置指南其中包含配置注册客户端前必须仔细考虑的重要元素。通用注意事项在动手配置前有几个来自 Authelia 官方集成文档的通用要点需要知晓内容源自 oidc-common 短代码模板client_id必须唯一每个客户端的client_id都必须是唯一值且只能包含 RFC3986 未保留字符长度不超过 100 字符。本文示例中的budibase仅为便于阅读和演示生产环境不应直接使用建议通过 Authelia 的随机生成能力生成 64 位随机字符。client_secret强烈建议以哈希形式存储示例中的insecure_secret仅是演示值。虽然明文存储当前仍被支持但该行为已被弃用不保证未来继续支持。以哈希形式存储时如果哈希工作因子work factor设置过高可能导致客户端请求超时详见调整工作因子相关 FAQ。配置示例并不完整下文给出的 Authelia YAML 片段只包含客户端注册部分你必须同时按 OpenID Connect 1.0 Provider 配置指南 完成 Provider 级必备配置同时该片段只覆盖了注册客户端众多可用选项中的一小部分建议完整阅读 OpenID Connect 1.0 客户端配置指南 以了解每个选项的作用与可选项。第一步在 Authelia 中注册 Budibase 客户端Authelia 的 OpenID Connect 1.0 提供方配置位于identity_providers.oidc之下。以下 YAML 是与上述应用示例配套的Authelia 客户端配置identity_providers: oidc: ## The other portions of the mandatory OpenID Connect 1.0 configuration go here. ## See: https://www.authelia.com/c/oidc clients: - client_id: budibase client_name: Budibase client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # The digest of insecure_secret. authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://budibase.example.com/api/global/auth/oidc/callback scopes: - openid - offline_access - profile - email response_types: - code grant_types: - authorization_code - refresh_token access_token_signed_response_alg: none userinfo_signed_response_alg: none token_endpoint_auth_method: client_secret_basic下面对每个关键字段逐一说明其作用与取值依据client_id / client_name / client_secretclient_idBudibase 在授权请求中使用的客户端标识取值budibase见配置文档。client_name客户端的展示名称仅在 Authelia 的管理界面等场景中用于标识取Budibase见配置文档。client_secret此处存放的是insecure_secret的PBKDF2-SHA512 摘要$pbkdf2-sha512$310000$...而非明文。这是 Authelia 强烈推荐的做法详见上文通用注意事项。authorization_policy取值为two_factor表示当 Budibase 用户发起授权时Authelia 将强制要求双因素认证。可选值还包括one_factor等详见授权策略配置。require_pkce / pkce_challenge_methodrequire_pkce: false当前不强制要求客户端使用 PKCEProof Key for Code Exchange。需要说明的是Authelia 对 PKCE 的支持属于其 OpenID Certified™ 认证套件的一部分原则上任何有能力执行S256变换的依赖方都应使用S256方法此处关闭是为了兼容 Budibase 的实现。pkce_challenge_method: 空字符串表示不限制挑战方法见配置文档。redirect_uris回调地址列表Budibase 完成 OIDC 认证后 Authelia 会将授权码重定向至此https://budibase.example.com/api/global/auth/oidc/callback该地址必须与 Budibase 侧展示的 Callback URL 完全一致见下文第二步。回调路径/api/global/auth/oidc/callback是 Budibase 内部处理 OIDC 回调的固定路径。scopes向 Authelia 请求的权限范围见配置文档openidOIDC 核心范围必选表示发起 OpenID Connect 认证请求。offline_access允许 Budibase 获取 Refresh Token用于在用户离线时刷新 Access Token 以维持会话。profile允许读取用户资料类声明如用户名、显示名等。email允许读取用户的电子邮件地址声明。response_types / grant_typesresponse_types: [code]只使用Authorization Code Flow授权码流程这是最安全、最标准的 Web 应用流程见响应类型说明。grant_types同时声明authorization_code授权码换取 Token与refresh_token刷新 Token两种授权类型后者需要配合前面的offline_access范围才能正常使用见授权类型说明。签名与端点认证access_token_signed_response_alg: noneAccess Token 不签名。从 Authelia 的默认实现看Access Token 默认是不透明opaque令牌而非 JWT详见 FAQ为什么 Access Token 不是 JWT因此这里显式声明none。userinfo_signed_response_alg: noneUserInfo 端点以普通 JSON 返回用户信息不做 JWT 签名见UserInfo 签名算法说明。token_endpoint_auth_method: client_secret_basicBudibase 在 Token 端点通过HTTP Basic AuthRFC 6749 定义的客户端认证方式携带 Client ID 与 Client Secret 进行认证见客户端认证方式说明。关于access_token_signed_response_alg: none还需要补充一点Authelia 的 OIDC 实现是OpenID Certified™的Basic OP / Implicit OP / Hybrid OP / Form Post OP / Config OP 五类 profile并支持none表示不签名/不加密。同时从 oidc-common 模板 可以看到集成第三方客户端时要注意客户端凭据编码类问题——client_secret_basic要求 Client ID 与 Client Secret 在使用前按 RFC6749 附录 B 进行 URL 转义因此务必避免在 Client ID/Secret 中使用特殊字符这正是示例选择纯小写字母数字值的原因。第二步在 Budibase 侧配置 OpenID ConnectBudibase 的 OIDC 配置只有一种方式Web GUI。无需自行编辑其服务端配置文件。可以跳过第 13 步直接访问以下 URL 进入组织设置https://budibase.example.com/builder/portal/settings/organisation配置组织信息通过以下任一方式进入组织设置页直接访问https://budibase.example.com/builder/portal/settings/organisation依次导航进入Builder 主页面→Settings设置→Organization组织。配置以下选项Org. name组织名称example.comPlatform URL平台地址https://budibase.example.com点击Save保存。如上图所示组织设置页位于 Budibase 的深色管理后台中标题为 Organisation除Org. name与Platform URL外还包含 Analytics 分析开关保存后这些信息将用于 Budibase 生成与 OIDC 相关的内部回调地址。配置 OpenID Connect 认证通过以下任一方式进入认证设置页直接访问https://budibase.example.com/builder/portal/settings/auth依次导航进入Builder 主页面→Settings设置→Auth认证→OpenID Connect。配置以下选项字段值Config URLhttps://auth.example.com/.well-known/openid-configurationClient IDbudibaseClient Secretinsecure_secretNameAutheliaIconauthelia.svg可从 Authelia 的品牌资源指南下载点击Save保存。关键字段解读Config URL即 Authelia 的 OpenID Connect Discovery 1.0 发现端点。Budibase 会拉取该地址返回的 JSON 元数据自动发现授权端点、Token 端点、UserInfo 端点、JWKS 等全部必要端点详见端点实现一览因此该 URL 必须指向 Authelia 根地址下的固定路径/.well-known/openid-configuration。Client ID / Client Secret必须与 Authelia 客户端配置中的client_id、以及client_secret对应的明文值保持一致——注意 Budibase 侧填写的是原始明文insecure_secret而 Authelia 配置文件里存储的是它的 PBKDF2 摘要两者通过摘要校验算法等价对应。Name / Icon用于自定义 Budibase 登录页上的 SSO 登录按钮文案与图标。从界面截图中还可以看到认证设置页包含Callback URL字段示例https://budibase.example.com/api/global/auth/oidc/callback与Auth Scopes字段默认值openid profile email offline_access前者与 Authelia 侧redirect_uris一一对应后者与 Authelia 侧scopes保持一致建议核对两者与 Authelia 配置中的值是否匹配。第三步验证集成完成上述两步配置后可通过以下方式验证集成是否生效访问 Budibase 登录页确认出现名为Authelia的 SSO 登录按钮点击该按钮浏览器应被重定向到 Authelia 的登录界面https://auth.example.com完成用户名/密码认证后若authorization_policy为two_factor还会继续要求第二因素如 TOTP、WebAuthn 等认证认证成功后浏览器应回跳到https://budibase.example.com/api/global/auth/oidc/callback随后自动登录 Budibase 后台。从实现层面看Budibase 属于使用授权码流程 Client Secret Basic 认证的标准机密客户端confidential client。整个登录链路对应 Authelia 的 授权码流程Budibase 先请求授权端点取得授权码再用client_secret_basic方式在 Token 端点换取 ID Token 与 Access Token最后通过 UserInfo 端点获取profile/email范围对应的用户声明。常见问题与排错建议登录按钮未出现或点击后报错优先检查 Budibase 的Config URL是否可访问直接在浏览器打开该地址应返回包含authorization_endpoint、token_endpoint等字段的 JSON 元数据。回调失败redirect_uri mismatchAuthelia 的redirect_uris与 Budibase 侧显示的 Callback URL 必须逐字符一致注意协议https、主机名、端口与路径/api/global/auth/oidc/callback都不能有差异。Token 交换失败确认 Budibase 侧填写的 Client Secret 明文与 Authelia 配置中摘要对应的原文一致同时确保 Client ID/Secret 中不含特殊字符参见通用注意事项中关于 RFC6749 附录 B 编码问题的说明。想开启更强校验可考虑将require_pkce设为true并指定pkce_challenge_method: S256前提是所用 Budibase 版本支持 PKCE。延伸阅读Budibase OpenID Connect 文档Budibase 官方文档Authelia OpenID Connect 1.0 集成总览Authelia OpenID Connect 1.0 客户端配置Authelia OpenID Connect 1.0 Provider 配置Authelia OIDC 常见问题FAQ【免费下载链接】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），仅供参考