[feature request] 建议增加 OIDC 单点登录的支持

[Oniokey]

描述

在团队使用本项目时，通常会建立统一身份服务，来串联起团队所使用到的各项服务
在个人使用本项目时，也会通过 Logto 等开源单点登录服务来简化各个系统间的身份问题
所以，建议增加单点登录的功能，可以优先考虑 OIDC/OAuth 2.0 作为单点登录的实现方式，通过 email 或 username 等字段将单点登录系统和业务系统（本项目）的用户关联起来

额外信息

SaToken 似乎有 OAuth 2.0 Client 的支持，但简略地看了下文档，似乎并不是标准的 OAuth 2.0 流程，可能需要自行实现相关流程
建议的流程是：

1. 后端增加 OIDC 配置相关的环境变量，例如 ClientID ClientSecret Issuer Endpoint Well-Known Endpoint
2. 通过 Well-Known Endpoint 获取必要的 code auth user_info 等端点
3. 执行标准 OIDC 流程
4. 后端服务得到用户信息后，根据 email 或 username 等字段关联用户

[zhaojun1998]

会考虑接入

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2025年5月2日(周五) 晚上7:19 收件人: ***@***.***>; 抄送: ***@***.***>; 主题: [zfile-dev/zfile] [feature request] 建议增加 `OIDC` 单点登录的支持 (Issue #737) Oniokey created an issue (zfile-dev/zfile#737) 描述 在团队使用本项目时，通常会建立统一身份服务，来串联起团队所使用到的各项服务 在个人使用本项目时，也会通过 Logto 等开源单点登录服务来简化各个系统间的身份问题 所以，建议增加单点登录的功能，可以优先考虑 OIDC/OAuth 2.0 作为单点登录的实现方式，通过 email 或 username 等字段将单点登录系统和业务系统（本项目）的用户关联起来 额外信息 SaToken 似乎有 OAuth 2.0 Client 的支持，但简略地看了下文档，似乎并不是标准的 OAuth 2.0 流程，可能需要自行实现相关流程 建议的流程是： 后端增加 OIDC 配置相关的环境变量，例如 ClientID ClientSecret Issuer Endpoint Well-Known Endpoint 通过 Well-Known Endpoint 获取必要的 code auth user_info 等端点 执行标准 OIDC 流程 后端服务得到用户信息后，根据 email 或 username 等字段关联用户 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Oniokey]

可以聊聊大致的实现思路，然后我可以按照思路和路线 pr

[zhaojun1998]

我需要等节后在看进行回复，pr也行，我自己开发也行。

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2025年5月2日(周五) 晚上7:49 收件人: ***@***.***>; 抄送: "zhao ***@***.******@***.***>; 主题: Re: [zfile-dev/zfile] [feature request] 建议增加 `OIDC` 单点登录的支持 (Issue #737) Oniokey left a comment (zfile-dev/zfile#737) 可以聊聊大致的实现思路，然后我可以按照思路和路线 pr — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[zhaojun1998]

@Oniokey

我看了下，其实就是实现标准的 OIDC / OAuth 2.0 协议，相关参数可以通过页面配置。

具体设计上：

• 配置应是多组的，可对接多个服务，除了基础的参数外，每个可单独控制是否启用(显示在登录页)，名称，图标(base64 or url)等信息。
• 用户管理应多一个虚拟用户，用来控制默认授予哪些存储源及权限给新用户。
• 增加配置控制是否允许新用户注册、如果不允许，则单点登录后该用户不在系统中，应给予相应提示。(之后再补充手动注册功能，因为还要考虑防刷)。
• 仅考虑支持 Authorization Code 授权模式。

开发测试上：

• OIDC 至少应在 authing、Sa Token OAuth2-Server Demo、Logto Cloud 上通过测试。
• OAuth 2.0 至少应在 Github 上通过测试。

这是一个大功能，可能需要的时间较长，优先级为中，欢迎 PR 来加快进度，如果有其他想法也可补充。

[Oniokey]

@zhaojun1998

了解，后续我给出相关 pr 推动这个功能

同时，有一些问题可能需要提前研究出方案

• 对于多服务接入的功能，可以采取预设服务商+通用服务商的方式，因为考虑到部分服务商的 OAuth2/OIDC 实现并不标准（可能只是在用词和表述上的），也可以简化开发，通过环境变量即可完成相关配置，减少对数据库的变更
• 在与原有用户系统集成上可能会有一些问题，包括 Sa Token 保存用户登录上下文等等，计划参考 Sa Token OAuth2 Client Demo 和 OAuth2-与登录会话实现数据互通
• 单点登录后若用户不存在与原系统中，可以考虑新建用户到一个默认低权限或无权限等，这个场景也是适应大多数团队的使用，同时考虑到单点登录本身也有较为完善的访问控制等，所以作为接入的子系统，在没有收到单点登录系统的授权码前，较难刷用户相关的接口
• 可能涉及到数据库结构的变更，用于记录相关配置信息等等，如何做好自动化数据库变更也是需要考虑的内容

[zhaojun1998]

• 不建议使用环境变量，绝大多数用户都是小白，非相关专业的，需要考虑到 docker 配置或修改环境变量需重建容器，且会给第一次使用的用户带来额外的心理负担，还是尽量人性化一些使用在线页面配置。
• 预设的我也考虑过，本来考虑的是专门写到文档中指导用户对接常见的服务，预设好的话就是开发上稍微麻烦些。
• 低权限或无权限就是我说的 "用户管理应多一个虚拟用户"。
• 自动化数据变更现在是通过 flyway 实现，在 src/main/resources/db 目录。

预想的页面大概是这样的（你可以实现核心功能，页面开发上和动态配置我来做）：

[zhaojun1998]

补充，尽量不引用额外的类库，工具类优先使用 im.zhaojun.zfile.core.util 中的或 hutool 的

[Oniokey]

wip pr #741

[zhaojun1998]

好的，谢谢。

[Oniokey]

后端这部分已经基本完成，可以看下有哪里是不合适的