ecnu-openapi 授权模式部分设计讨论

[dbbDylan]

背景

基于已有的 README.md ，进一步完成 #TODO 事项，并对已有功能作一些探讨、维护和进一步的集成。

此 issue 聚焦在第一部分：授权模式。其余两部分的内容只做维护而不做任何功能 / 使用方式上的改变和任何已知 / 未知 bug 的修复。

授权模式

参考：华东师范大学开发者平台 | 授权模式

计划支持（已实现：√）：

• 授权码模式（authorization code）
• 客户端模式（client credentials）
• 资源拥有密码模式（Resource Owner Password Credentials）

设计思路

以下内容，不同的 sdk 是否考虑集成各自语言的 Swagger UI 以供调试呢？

• 现状: 目前 sdk 只实现了一种认证方式，且没有进行封装
• 目标: 用户使用 sdk 时，只关心使用哪种认证方式并传入认证所需要的信息（包括基本信息，例如 client_id 和 client_secret；类型信息，grant_type；认证特殊信息，例如资源拥有密码模式下的 username 和 password），而不关注具体的认证流程。

因此，期望将不同 OAuth 模式构造成适配器模式，不同的模式互为不同的 adaptor 。这样，鉴权对外暴露的接口只剩下以下几个：

• getAccessToken：获取 access token
• refreshAccessToken：刷新 access token

如何处理额外的 authentic code 获持？

不同的认证模式可能会走额外的鉴权流程以获取不同额外的鉴权信息，例如 authentic code。这部分方法应该被不同的适配器私有化，通过拦截器实现，并尽可能做好封装（指无需用户指定，自动调用，这部分内容需要讨论）。

接口规范

1. 上面提到的 Swagger UI，是否搞一个？
2. 遵循不同语言命名的最佳实践

任务安排

1. Code Review，先把这个 PR 处理掉
2. 在此基础上，重新实现 /sdk 部分的鉴权模式
3. 补充和修改 example 使用样例

[freedomkk-qfeng]

这是定位给学校开放平台的 sdk，不是 oauth2 的 sdk，那个在各种语言上已经有实现了，我们没必要重新造轮子。
定位给学校开放平台的 sdk，则核心应该考虑让用户忽略掉 token 管理的过程。
换言,getAccessToken 和 refreshAccessToken 虽然也可以作为开放的接口之一，但重要的部分应该是拿到 token 以后的工作。

这里在 client credentials 部分实现的部分是 callAPI 和 批量同步的深度封装。

而对于后续的 authorization code/password/pkce/device code ，则应该主要考虑认证，也就是直接拿到 userinfo 的信息。考虑对 其他 oauth2 server 协议的兼容，我们可以考虑封装为输出一个 map/dict 作为通用的 userinfo 返回，并另外专门写一个 getECNUUser(这命名好难受）的方法，来返回结构化的用户信息（也就是 /oauth2/userinfo 那个）。

这里不同模式下应该通用的方法可以有 getAccessToken，callAPI。其他的还是和各自的场景有关，很难完全统一（refreshToken勉强多一点），这个封装在一起，还是分开，我觉得可以讨论。但无论如何可能都会和目前的机制产生一些破坏行变更（会吗？），所以可以做一个 sdkv2。

拦截器的实现和 http 的框架有关，这部分 sdk 不应该做，做了就太耦合了。但我们应该在 example 里给出一种主流的 http 框架下拦截器的实现参考，有助于用户快速应用。