Yggdrasil Connect 协议支持

[tnqzh123]

检查项

• 我充分理解提交的建议可能无法所有启动器作者参与，并尊重所有启动器开发者的选择
• 我确认在Issues列表中并无其他人已经提出过与此问题相同或相似的问题
• 我确认该反馈并非针对单个启动器的，如果是，我将会去该启动器的反馈页面反馈

您是什么类型的用户

第三方网站管理/负责人（MC相关的）

请简单的说一下您的想法

Yggdrasil Connect 是基于 OpenID Connect 协议的全新用户身份认证协议，为 authlib-injector 外置登录提供了一种基于 OAuth 2.0 和 OpenID Connect 的用户身份认证解决方案，目的是取代 Yggdrasil API 中的 Auth Server 部分。

目前 LittleSkin 已实现支持 OAuth 2.0 设备代码流的 Yggdrasil Connect 服务端。

它能解决什么样的问题/带来什么样的帮助

在 Yggdrasil API 的 Auth Server 部分中，用户需要将自己的用户名和密码直接暴露给第三方应用，才能通过第三方应用访问 Yggdrasil API，这增加了用户账户关键信息泄露的风险；且该部分的 API 在设计上几乎没有考虑到二步验证，无法良好地保障用户账户的安全。并且，由于各个第三方应用在该部分 API 的实现存在差异，用户在不同应用之间的登录体验存在较大割裂，时常出现应用实现不完整导致用户无法正常登录、用户体验低下的问题（例如 Hex-Dragon/PCL2#3519、Xcube-Studio/Natsurainko.FluentLauncher#281）。

Yggdrasil Connect 的目的即是解决这些问题。通过 OAuth 2.0 和 OpenID Connect 协议，Yggdrasil Connect 可以实现用户在不同应用间的登录体验的统一，同时方便各验证服务器自行设计用户身份认证方式，以保障用户账户的安全。

期望的结果

启动器需要实现一个 OpenID Connect 客户端（可由 OAuth 2.0 客户端扩展而来），允许用户通过 OAuth 2.0 登录 authlib-injector 外置登录账号，就像登录微软正版账号一样。

大致流程：通过 OAuth 2.0 请求授权 -> 解码 ID Token / 请求 UserInfo Endpoint 拿角色信息（不需要再处理角色选择！）-> 把 OAuth 的 Access Token 直接传进游戏里

Yggdrasil Connect 的登录流程相较微软正版登录的流程要简单很多，而且 OAuth 2.0 客户端部分的大部分代码应该都可以复用。

是否有对这个方案的相关链接？

Yggdrasil Connect 规范（公开评审版本）：yushijinhun/authlib-injector#268

该规范包含服务端规范和客户端规范，目前仍为公开评审版本，但应该不会有比较大的变更。欢迎各位就公开评审版本提出评审意见或建议。

启动器作者如果觉得完整的规范太长，想要个《启动器要怎么做才能实现 Yggdrasil Connect 客户端》，可以先看完整规范的「服务发现」章节、「授权流程」章节和「用户信息获取」章节，可以结合 LittleSkin 的 OAuth 2.0 设备代码流文档一起看：https://manual.littlesk.in/advanced/oauth2/device-authorization-grant

附注

HMCL 有一个 PR 针对 LittleSkin 实现了 Yggdrasil Connect 客户端：HMCL-dev/HMCL#3491，各位可以前往 Actions 中下载编译好的版本来体验：https://github.com/HMCL-dev/HMCL/actions/runs/12237584465

[shimoranla]

Note

我知道这个建议有可能不会采纳，甚至在专业人士看来可能很蠢，但是我认为这确实需要解决

应用注册

应用必须事先在认证服务器上注册，并获取应用标识符，然后才能请求用户授权。

Yggdrasil Connect 支持的应用注册方式有三种：
主动注册
动态注册
公用应用

认证服务器应至少支持上述三种应用注册方式中的一种。

目的是取代 Yggdrasil API 中的 Auth Server 部分。

就这个目的来说，我认为应用注册不能只支持一种，而是应该至少支持两种，例如 主动注册+动态注册 或 主动注册+公用应用

理由

无论是现有启动器的接入亦或是未来新的启动器开发，主动注册都不会成为长久之计（除非能有个第三方来提供统一的 Client ID 注册，但就目前这个环境下我认为不太现实，启动器作者之间都不服对方，难保皮肤站之间不会这样），而剩下的注册方式在这个前提条件下又是可选特性，那么只要皮肤站开发者偷点懒不想做或者管理员出于安全考虑禁用这些注册方式，启动器作者就要消耗额外的时间成本去处理注册问题，也就不可能达到取代 Auth Server 部分这个目标

摘自 Hex-Dragon/PCL2#775

这代表我能花在 PCL 上的时间是 非常有限 的，我需要把有限的开发时间花在改进更大、收益更高的地方。所以，当有许多改进建议摆在我面前时，我只能无情地选择 能用上它的人最多的、制作耗时最少的、对体验优化最大的 功能。

各个启动器作者之间都或多或少面临这样的矛盾（甚至非商业化的团队开发也不例外），他们自己的 Issue 都没处理完，没有精力去全部注册一遍（事实上这也不可能），如果只要求至少支持其中一种，那么启动器作者只会也只能考虑接入 LittleSkin 等知名、稳定且用户数量特别多皮肤站，小众皮肤站只能使用传统登录的方式继续运行（LittleSkin 作为国内知名的皮肤站之一兼 Yggdrasil Connect 协议草案的制定者和实现者都没停掉这种登录方式，显然无法应用此协议的皮肤站更不可能停掉）

在这个条件下，这个协议的开发收益并没有特别高，启动器作者也不会有动力去接入这个协议，因为这个协议只是解决了不同启动器/操作系统平台登录体验不统一的问题和提高了账号安全性（或者更多，但是我没细看），但安全问题本身可能就不在特定启动器作者的特殊考虑之下，用户体验又可以改进（虽然不能完全解决体验割裂感，但至少不会出现大部分用户无法接受这种情况（Hex-Dragon/PCL2#3519 不就一直没人反馈么）），那么这个协议剩下的亮点只有多因素身份认证和皮肤站实现的额外特性..... 吐槽：（说人话就是有点用处但不多）

这个问题不应该只有我能看得出来，所以我认为这个部分需要修改

[tnqzh123]

@shimoranla 针对规范的评审建议和意见，我建议发到 yushijinhun/authlib-injector#268，以方便跟踪，毕竟规范是在那个 issue 请求评审的，这个 issue 是个 feature request。

---

你说的不是没有道理，但我总觉得你是不是搞错了什么？

各个启动器作者之间都或多或少面临这样的矛盾（甚至非商业化的团队开发也不例外），他们自己的 Issue 都没处理完，没有精力去全部注册一遍（事实上这也不可能），如果只要求至少支持其中一种，那么启动器作者只会也只能考虑接入 LittleSkin 等知名、稳定且用户数量特别多皮肤站，小众皮肤站只能使用传统登录的方式继续运行...

虽然说 Yggdrasil Connect 的目的是“取代 Yggdrasil API 中的 Auth Server 部分”，但这并不表示传统 Auth Server 和 Yggdrasil Connect 不能共存。认证服务器完全可以同时实现传统 Auth Server 与 Yggdrasil Connect，就像 LittleSkin 现在这样。

服务发现的目的就是让第三方应用了解到认证服务器支持什么样的认证方式，如果启动器在服务发现过程中发现其 Yggdrasil Connect 实现与认证服务器不能交互，那启动器也完全可以尝试回退到传统 Auth Server。但说到底，启动器如何实现 authlib-injector 外置登录是启动器作者的自由。

（LittleSkin 作为国内知名的皮肤站之一兼 Yggdrasil Connect 协议草案的制定者和实现者都没停掉这种登录方式，显然无法应用此协议的皮肤站更不可能停掉）

LittleSkin 目前仍然支持传统 Auth Server 是出于兼容性考虑，毕竟目前规范仍在草案和公开评审阶段，除了 HMCL 的那个预览版之外没有别的启动器支持 Yggdrasil Connect，这种情况下直接一刀切会导致绝大部分用户无法正常登录，对用户体验来说并不友好。但这并不代表 LittleSkin 没有计划砍掉传统 Auth Server，这点在我们的 roadmap 中是明确的，用户使用手册中也有提到: Link

至于后半句，考虑到目前几乎所有 Yggdrasil 认证服务器都是基于 Blessing Skin 的，只要 Blessing Skin 这边提供了 Yggdrasil Connect 支持，砍掉传统 Auth Server 也不是不可能的事。

... 但安全问题本身可能就不在启动器作者的特殊考虑之下 ...

你这说的还是人话吗…有谁能不考虑信息安全问题？

... 用户体验又可以改进（虽然不能完全解决体验割裂感，但至少不会出现大部分用户无法接受这种情况（Hex-Dragon/PCL2#3519 不就一直没人反馈么）...

我不想岁月史书，但是你提到的这个 issue 中描述的问题我在 2020 年高考前夕就通过 QQ 私聊和龙猫提过了，当时说的是「建议在网络请求中添加 Accept-Language 头，这样基于 Blessing Skin 的皮肤站可以根据用户的偏好语言返回对应的错误文本」，而龙猫当时给我的答复是「没必要，PCL 里用不到这些错误信息」，他都这么说了我能怎么办…如果我能把我的小米 6 找出来并且修开机的话没准还能找到当时的聊天记录…

而且 LittleSkin 收到了一堆你提到的这个 issue 中的问题相关的提问，我在你提到的这个 issue 的评论中也有说明过。

... 那么这个协议剩下的亮点只有多因素身份认证和皮肤站实现的额外特性..... 吐槽：（说人话就是有点用处但不多）

你觉得“有点用但用处不多”是因为现在摆在明面上的需求就这么多。

Yggdrasil Connect 授权过程相当于把登录流程中的大部分 UX 设计问题（包括以前由启动器处理的角色选择问题）都交给了认证服务器这边，启动器只要做好请求授权和错误处理时的 UX 就好了，相当于是给启动器这边解耦 UX，之后认证服务器要整什么花活也都是认证服务器在 Web 端自己实现，和启动器没关系了。虽然不能说是一劳永逸，但多少也为认证服务器拓展自己的功能提供了基础支持。

---

不论如何，你说的问题确实有道理。我会再仔细考虑一下。

[tnqzh123]

手误点到了 close…sry

@ZhaiSoul 能不能帮我 reopen 一下？我这显示没权限…

[IceCream-QAQ]

请从启动器的角度描述，该请求给启动器带来了什么好处。

#11 (comment)
#16 (comment)

我对所有提案一视同仁。
请给出能打动启动器开发者的条件，启动器开发者才愿意给你做事。

[shimoranla]

你这说的还是人话吗…有谁能不考虑信息安全问题？

你去看看 PCL2 ，他甚至默认关闭 SSL 校验（虽然是被迫的

Edit:（Man-in-the-middle Attack Warning）

Edit2:也没有指代全部（虽然表述有误

Edit3:虽然在新设备使用的时候我是倾向于打开的

[tnqzh123]

@IceCream-QAQ

请从启动器的角度描述，该请求给启动器带来了什么好处。

请给出能打动启动器开发者的条件，启动器开发者才愿意给你做事。

我不理解你说的“该请求给启动器带来了什么好处”、“打动启动器开发者”是什么意思。

启动器写出来是为了给最终用户提供服务的，外置登录认证服务器也是给最终用户提供服务的，优化最终用户的账户安全和用户体验我认为就已经是足够的理由了。

如果你非要谈“给启动器带来了什么好处”的话：

1. 启动器外置登录流程和验证服务器的实现解耦，验证服务器可自行选择用户认证方式，并针对自身特性提供更多功能，而启动器只需要一套代码就能完全兼容；
2. 如果以后有盗号事件，只要启动器没有泄露 Token，用户就不会怀疑到启动器的头上——因为启动器根本接触不到用户登录时使用的凭据。

[IceCream-QAQ]

如果你非要谈“给启动器带来了什么好处”的话，如果以后有盗号事件，只要启动器没有泄露 Token，用户就不会怀疑到启动器的头上——因为启动器根本接触不到用户登录时使用的凭据。

首先，盗号盗的不是启动器的号，是 皮肤站/第三方登录 的账号，皮肤站/第三方登录 的账号安全内容，应该由 皮肤站/第三方登录 自己保证，而不是启动器保证。
我已经提供过包括但不限于，临时密码，等提议。
但均被你否定了。
用户是否能登录上去的最终验证归属于 皮肤站/第三方登录，而不是启动器，你不应该捆绑启动器开发者为你服务。
有密码不是一定能登得上去账户，谢谢。

启动器写出来是为了给最终用户提供服务的，外置登录认证服务器也是给最终用户提供服务的，优化最终用户的账户安全和用户体验我认为就已经是足够的理由了。

最终优化的，不是用户对启动器的使用体验，是用户对 皮肤站/第三方登录 的使用体验。
启动器在这一流程中几乎没有收获。
你不能以你 为了 用户 对 你 服务的体验，来要求启动器做改进。

[tnqzh123]

@IceCream-QAQ

首先，盗号盗的不是启动器的号，是 皮肤站/第三方登录 的账号，皮肤站/第三方登录 的账号安全内容，应该由 皮肤站/第三方登录 自己保证，而不是启动器保证。

我觉得你没有弄清楚一件事：外置登录账号就是 MC 游戏服务器的账号。

authlib-injector 外置登录方案中，玩家身份信息都是由验证服务器提供的。如果验证服务器账号被盗，等于说玩家的游戏账号被盗。别有用心的人可以拿着被盗的账号，登录受害者游玩的 MC 服务器，把他背包和箱子里的所有物品都扔进岩浆里，或者直接破坏服务器存档。

那么最常接触到这个账号的登录凭证的人，除了玩家自己和验证服务器，还有谁呢？对了，启动器。

如果我没有记错的话，现在仍然有部分启动器是会保存用户的外置登录密码的。

我已经提供过包括但不限于，临时密码，等提议。

临时密码、App Password 或者 Personal Access Token 只不过是另一个密码，其与传统的单因素认证并无区别。或许临时密码由于其生成的随机性无法被简单猜到，但仍有泄露的可能。

有人在群内拿 GitHub 举例，但我认为这个例子并不能简单直接地套用到外置登录场景上。GitHub 的 PAT 可以针对 PAT 的权限范围做出详细的限制，但外置登录场景一共就只有一个权限范围（进入服务器），做不到更精细的权限范围限制。

用户是否能登录上去的最终验证归属于 皮肤站/第三方登录，而不是启动器，你不应该捆绑启动器开发者为你服务。
有密码不是一定能登得上去账户，谢谢。

你说得对，但你这几句话也同时否定了现在的外置登录认证方案（直接 POST 用户名和密码）。

启动器在这一流程中几乎没有收获。

我在上面的 comment 提到了两点，在此不再赘述。

[IceCream-QAQ]

我觉得你没有弄清楚一件事：外置登录账号就是 MC 游戏服务器的账号。

对，没错，但和 启动器 有什么玩意。
当年使用登录 插件/Mod 的时代也没有人来要求启动器做什么啊。

或许临时密码由于其生成的随机性无法被简单猜到，但仍有泄露的可能。

对没错，但 设备代码 可能无法被简单猜到，但仍有泄露的可能。

但外置登录场景一共就只有一个权限范围（进入服务器），做不到更精细的权限范围限制。

能不能进服务器，已经是 皮肤站/第三方登录 和 服务器 之间的事情了，和启动器完全无关。
启动器提供一个 假 Token，授权服务给过了就是可以过。
启动器提供一个 真 Token，授权服务器不给过就是不给过。

能不能过授权在于你，而不在于启动器。

你说得对，但你这几句话也同时否定了现在的外置登录认证方案（直接 POST 用户名和密码）。

我否定所有登录方案，因为没有任何一个方案的权限控制在启动器手里。
所以启动器不应该为任何方案的安全性负责。

[bangbang93]

由于上游意见为重新讨论，现关闭本issue。待上游意见统一后再跟进。