最近红岩网校的同事接了一个单子，需要做一个app，用户是校内学生，由于时间紧迫，不想自己写用户系统，于是便打算复用掌上重邮的登录功能。我们知道在大多数场景下，一方作为身份提供者给另一方服务提供认证功能时，涉及到登录，凭据交换等环节，而OAuth，OIDC就是为了规范这些环节每一步之间应该传递的内容而提出的，OAuth主要是用于授权，OIDC在OAuth2上扩展而来，用于身份认证，区别在于前者是绑定了你的QQ，可以获取你的好友，昵称，签名等信息，另后者则是使用你的QQ在目标平台上创建一个新的账户。
不过可惜的是，掌上重邮并没有实现OIDC Provider，即它不能作为身份认证提供者通过OIDC给其他服务提供用户信息。不过我已经压力小登去实现了，借助掌邮自带的全校学生数据，实现了OIDC对后期外部业务帮助很大。
正文
Misskey是一个去中心化的社交平台，既然是社交平台，那就必然有用户系统，也就有一整套认证体系，也就是说它可以像QQ微信那样，作为认证方给其他应用提供身份认证。Misskey官方也是有OAuth2提供者实现的，具体方式可以参照Misskey OAuth2认证文档，不过Misskey的OAuth2流程和业内常用的不太一样，首先我们会在提供方那里创建App，Misskey的做法是创建一个可访问的网页，然后在网页中塞入一些元数据实现应用的定义，我们在应用程序中把这个储存应用信息的网站url作为client_id传给misskey认证端点。后续就和常规流程差不多，不过我试过了，基本上不是这报错就是那报错，例如，client_id指向的站点域名不能解析到非法IP地址，我当时指向的是C类保留地址段192.168.0.0/16的一个IP。后面就一直提醒我invalid redirect_uri，这里我是真的没办法了，遂放弃
不过Misskey还提供了一种认证方式，叫做MiAuth，咋一看像是小米账号(不是)，MiAuth流程比OAuth2授权码模式简单，只需要两步，且无需创建应用：
在应用服务端生成session，一个随机字符串，并暂存在服务端，然后拼接成https://{host}/miauth/session返回给前端，其中还可以带上查询参数来告诉misskey应用信息：name=名称；icon=图标；permission=权限范围；callback=回调地址(必须)，我们需要获取用户信息，需要permission="read:account"。
前端拿到这个url点击打开Misskey的认证页面，Misskey会进行基本的授权询问，同意后会重定向到这个回调地址，并附带了第一步的session作为查询参数，应用后端需要拿到session并校验合法性，然后在后端请求https://{host}/api/miauth/{session}/check，可以在返回json拿到token和
user两个字段，user便是用户信息，其中id是唯一字段，可以用来做身份识别。
至此我们便完成了Misskey给第三方应用进行认证的流程，目前neo-blog已经支持配置misskey实例作为身份提供者，需要在oidc_config中指定type字段misskey
总结
我个人感觉这种认证方式没有太多安全性可言，任何不认识的应用都可以将用户重定向到Misskey站点登录并获取token，从而获取到用户对应的权限；如果有恶意应用引导用户到Misskey登录那后果不堪设想，标准OAuth授权码流程是要在两边配置client_id和client_secret来防止恶意应用获取信息。
