Authelia 集成 Memos配置 OpenID Connect 1.0 实现 Web 应用单点登录【免费下载链接】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 仓库中的 Memos 集成文档 为骨架讲解如何将 Memos开源备忘录/笔记应用接入 Authelia 的 OpenID Connect 1.0 Provider实现由 Authelia 统一托管的单点登录SSO。读完本文你将掌握 Authelia 侧 OIDC 客户端的完整 YAML 配置、Memos 侧 Web GUI 的 SSO 参数填写方法以及该集成背后涉及到的端点调用链与安全注意事项可直接复制到自己的生产环境中落地。测试版本与适用前提官方文档针对以下版本组合完成了联调验证这是该集成指南的事实基准Autheliav4.38.0Memosv0.16.1需要说明的是Memos 通过其设置界面的SSO模块以OAuth2 客户端的身份接入 Authelia属于 OpenID Connect 1.0 集成参考 体系下的一个 Relying Party 实现案例。该文档标注的支持级别为 community社区维护、integration: true意味着配置方法会随 Memos 与 Authelia 版本演进而变化升级版本后建议重新核对两端配置。集成前的假设与准备基本假设本示例基于以下约定展开你可以将其替换为实际域名项目值应用根 URLMemoshttps://memos.example.com/Authelia 根 URLhttps://auth.example.com/Client IDmemosClient Secretinsecure_secret配置 OpenID Connect 1.0 客户端前的重要阅读在正式配置前有几个来自 Authelia 官方 OIDC 公共注意事项 的约束必须了解client_id 约束每个客户端必须唯一文档示例值仅为可读性演示生产环境应使用 随机生成的客户端标识符官方推荐 64 个随机字符只允许包含 RFC3986 非保留字符长度不超过 100 字符。client_secret 约束示例值insecure_secret仅用于演示生产环境绝对不要使用secret 可以明文存储于配置中但该行为已弃用未来版本不保证继续支持强烈推荐以哈希形式存储如下文 YAML 中的$pbkdf2-sha512$...格式。当 secret 以哈希存储时哈希成本work factor过高可能导致客户端超时可参考 调优 work factors。配置完整性下文给出的 YAML 仅是客户端注册的示例配置你还必须按照 OpenID Connect 1.0 Provider 配置 完成 Provider 层的必填项如 issuer、密钥等同时应通读 OpenID Connect 1.0 Clients 配置 熟悉其余可用选项。Authelia 侧注册 Memos 为 OIDC 客户端完整示例配置将以下片段合并进 Authelia 的configuration.yml中identity_providers.oidc部分identity_providers: oidc: ## OpenID Connect 1.0 Provider 的其余必填配置放在这里。 clients: - client_id: memos client_name: Memos client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # insecure_secret 的摘要。 public: false authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://memos.example.com/auth/callback scopes: - openid - profile - email response_types: - code grant_types: - authorization_code access_token_signed_response_alg: none userinfo_signed_response_alg: none token_endpoint_auth_method: client_secret_post关键参数逐项解析以下参数说明综合自 Clients 配置文档 与 配置 Schema 源码client_id / client_name客户端唯一标识与 UI 展示名。client_name默认与 id 相同仅在界面上显示不影响协议行为。client_secretAuthelia 与 Memos 共享的机密。示例中给出的$pbkdf2-sha512$...是insecure_secret的 PBKDF2-SHA512 哈希摘要迭代 310000 次这正是secret 哈希存储的推荐形态。可通过authelia crypto hash generate pbkdf2 --variant sha512类命令生成自己的摘要见 commands/crypto_hash.go。public: false声明为机密confidential客户端类型。Memos 是服务端应用能够安全保管 secret因此不应设为 publicpublic 要求 secret 为空字符串。authorization_policy: two_factor该客户端在授权请求时要求用户完成双因素认证。取值可以是one_factor、two_factor或 Provider 层authorization_policies中自定义的策略名。校验逻辑见 validator/identity_providers.go非法值会直接报错拒绝启动。require_pkce: false / pkce_challenge_method: 本示例未强制 PKCE。需要说明的是pkce_challenge_method若配置为S256或plain会同时隐式启用require_pkce官方强烈建议 Relying Party 支持时使用S256。Memos 当前版本的 OAuth2 客户端能力有限故文档按关闭状态配置安全加固建议见文末。redirect_uris回调白名单必须与 Memos 实际回调地址完全一致且大小写敏感https://memos.example.com/auth/callback是 Memos 的 OAuth2 回调路径。不在列表中的 URI 会被拒绝授权。scopesopenid、profile、email与 Memos 端声明的 Scopes 对应。scope 定义见 OpenID Connect 1.0 Claims 参考。response_types: [code]仅启用授权码流程Authorization Code Flow这是官方推荐的最安全响应类型。Schema 源码允许的取值还包括id_token、token、code token等隐式/混合流程值但均不如此处安全。grant_types: [authorization_code]仅允许授权码授权方式。access_token_signed_response_alg: none / userinfo_signed_response_alg: noneAccess Token 与 UserInfo 响应不签名Memos 按普通 JSON 解析 UserInfo。若改为非none值Access Token 将按 RFC9068 编码为 JWTUserInfo 则返回application/jwt格式多数客户端并不支持保持none即可。token_endpoint_auth_method: client_secret_postMemos 通过 HTTP POST body 提交 client_id 与 client_secret 向 Token 端点认证。这是 Memos 支持的方式若发现认证失败需先确认客户端是否对凭证做了 RFC6749 Appendix B 所要求的 URL 编码见下文已知注意事项。Memos 侧通过 Web GUI 配置 SSOMemos 的配置只有一种方式Web GUI。操作步骤如下进入 Memos 的设置菜单选择SSO点击create并选择类型OAuth2。模板选择custom自定义。按下表填写各字段字段值NameAutheliaClient IDmemosClient secretinsecure_secretAuthorization endpointhttps://auth.example.com/api/oidc/authorizationToken endpointhttps://auth.example.com/api/oidc/tokenUser endpointhttps://auth.example.com/api/oidc/userinfoScopesopenid profile emailIdentifierpreferred_usernameDisplay Namegiven_nameEmailemail端点在 Authelia 中的真实实现Memos 填写的三个端点并非虚构它们由 internal/server/handlers.go 中的路由注册真实提供均挂在 Authelia 根 URL 下GET/POST /api/oidc/authorization→ 授权端点处理OAuth2AuthorizationGET/POST实现见 handler_oauth2_authorization.go其中会调用NewAuthorizeRequest构造并校验授权请求且支持 Pushed Authorization Request 检测。POST /api/oidc/token→ Token 端点兑换授权码、签发令牌。GET/POST /api/oidc/userinfo→ UserInfo 端点返回用户声明claims。更完整的端点清单含.well-known/openid-configuration发现端点、/jwks.json、introspection、revocation 等可参考 OpenID Connect 1.0 集成介绍。Memos 这类不支持发现机制的客户端正是按文档中这些固定路径手工填写的场景。字段映射的含义Scopes与 Authelia 客户端配置中的 scopes 一一对应缺少任何一个都会导致 UserInfo 返回的声明不全。Identifier / Display Name / EmailMemos 从 UserInfo 响应中提取的声明映射。preferred_username对应profilescope 下的用户名声明given_name对应显示名email对应邮箱声明。Memos 将据此建立本地账号与登录身份的关联。登录流程一次完整的 SSO 交互配置完成后用户访问 Memos 并点击 OAuth2 登录时实际发生的调用链为浏览器重定向至 Authelia 授权端点https://auth.example.com/api/oidc/authorization携带client_idmemos、redirect_uri、response_typecode、scope等参数。Authelia 校验客户端与回调地址后展示登录页由于authorization_policy: two_factor用户需完成第一因素密码与第二因素认证。认证通过后浏览器携带授权码回调到https://memos.example.com/auth/callback。Memos 后端以client_secret_post方式携带凭证向 Token 端点POST /api/oidc/token兑换 ID Token 与 Access Token。Memos 调用 UserInfo 端点https://auth.example.com/api/oidc/userinfo获取preferred_username、given_name、email等声明完成本地账号绑定与会话建立。上述端点在 Authelia 侧均经过限流rate limit与 CORS 中间件处理相关中间件配置可参考 internal/middlewares/rate_limiting.go 与 internal/middlewares/cors.go。已知注意事项与安全加固建议结合 OIDC 公共注意事项 与本文配置以下几点需要特别留意凭证编码问题若你在 Memos 中使用包含特殊字符的 Client ID / Client Secret可能因客户端未按 RFC6749 Appendix B 做 URL 转义而导致认证失败。规避手段是避免在凭证中使用特殊字符或使用 Authelia 随机密码生成器输出的预编码版本。Claim 稳定性OpenID Connect 规范5.7 节要求依赖方以稳定的sub声明绑定本地账号而非可变的email/preferred_username。若 Memos 以邮箱等可变声明作为账号标识需知悉其潜在的身份混淆风险建议关注 Memos 后续版本是否改进。启用 PKCE若你使用的 Memos 版本支持 PKCE强烈建议将 Authelia 侧改为require_pkce: true与pkce_challenge_method: S256以缓解授权码拦截攻击。更换演示凭证上线前必须将memos/insecure_secret替换为随机生成的值并优先使用 PBKDF2-SHA512 哈希存储 secret与上文 YAML 中的$pbkdf2-sha512$格式一致避免明文。回调地址精确匹配redirect_uris大小写敏感且必须与 Memos 实际回调完全一致配置错误会直接导致授权失败。延伸阅读OpenID Connect 1.0 集成介绍端到端了解 Authelia 支持的响应类型、响应模式、授权类型、客户端认证方法与端点实现。OpenID Connect 1.0 Clients 配置本文涉及参数的完整参考以及jwks、consent_mode、claims_policy等进阶选项。OpenID Connect 1.0 Provider 配置Provider 层必填项issuer、密钥、lifespans 等。OpenID Connect 1.0 常见问题客户端标识符与 secret 的生成方法、work factors 调优、明文存储弃用说明等。【免费下载链接】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），仅供参考