Authentication oauth2相对于简单登录的优势？

如果目标是为各种断开连接的应用程序提供登录功能，那么将其构建为oauth2提供商（例如openid connect）与提供简单登录相比是否有优势

换句话说，我看到了两个选项，每个选项都会从各种应用程序触发一个窗口：

选项#1：“登录”打开一个登录页面，提示后端的oauth2流，并最终返回成功（使用用户ID和访问令牌）或失败。成功后，令牌用于后续通信（即获取配置文件数据或其他信息）

选项#2：“登录”打开一个登录页面，该页面只需对照数据库检查用户名/密码，并返回success（带userid）或fail。成功后，它会创建一个会话用于后续通信（即获取配置文件数据或其他信息）

使用选项1有什么实际优势吗？假设第三方应用程序不是向世界开放的，而是可以使用任何一种方法的协作项目

每个客户端应用程序之间的单点登录

• 不言自明

用于与共享资源服务器（API）通信的用户特定访问令牌

• 假设选项2（没有OAuth），则不一定有任何令牌（尽管可能有）…只有登录的每个客户端应用的会话cookie

本身包含用户信息的id令牌JWT

• 好处很小，但不是通过身份验证然后请求配置文件数据（在选项2中），使用JWT可以获得配置文件数据作为身份验证响应的一部分

将该问题与每个客户端应用程序分离的单一身份验证机制

• 在选项2中，每个客户端应用程序都需要处理与DB的身份验证。在选项1中，授权服务器在一个地方处理这个问题

---

等等-但我不明白，在一个常规的ol'会话中，除了单点登录之外，你不知道所有这些吗？i、 e.如果他们需要为每个应用程序重新登录，那么由于会话原因，他们仍然会被所有api调用的用户id跟踪。。。。