re-construct oauth

[IamTaoChen]

有点乱

变化

1. 在user中增加了email
2. 重构Oauth的逻辑
3. 修改了oauths表
4. 修改了user_thirds
5. 设备注销的时候，在Peer中取消uuid和uer的关联
6. 在用户界面，新增加“我的设备” 来展示已经登陆的客户端

说明

Oauth自动注册变化

1. 如果存在与Oauth中email的用户，则不会创建新用户，而是直接关联
2. 如果用户不存在，创建用户的时候会使用Oauth中的Username（不同类型会使用不同的field), Name 和Email

Oauth 认证流程变化

1. Oauth将根据不同类型来执行不同的流程，当前有4种类型，OIDC, GitHub, Google 和 Webauth
2. 客户端提供op (Oauth Provider), 后端会在设置中查找其对应的类型，然后执行不同的逻辑

前端对应PR:lejianwen/rustdesk-api-web/pull/5

数据库迁移

• [ ] 注意要对数据库进行迁移才可以正常运行
• [x] 验证google认证
• [x] 验证Github认证
• [x] 验证OIDC认证(Keycloak)

[lejianwen]

1. 测试了一下github，在scopes为空时，没有email，然后会导致通过email找用户直接找到第一个没有email的，会直接绑定
2. 第一授权自动注册用户时，会提示授权注册失败

[IamTaoChen]

1. 测试了一下github，在scopes为空时，没有email，然后会导致通过email找用户直接找到第一个没有email的，会直接绑定

• [x] github 需要单独获取email, 已解决
• [x] 如果没有email返回，现在会使用username@op, 小写

2. 第一授权自动注册用户时，会提示授权注册失败

• [x] Oauth注册用户的时候，返回了一个空user, 已解决

[lejianwen]

您好，首先感谢您的RP 我测试了一部分，也修改了一部分，基本都OK了，但我发现我们可能走错了一条路 OIDC 应该是包含了 google ，Keycloak，Okta等等，github因为没有公开的端点，所以无法使用通用的OIDC 也就是说我们应该可以创建多个OIDC来进行授权，只是服务商不同 而像google这种支持通用方式处理的，可以选择内置在代码中，后台选择google时自动填充对应的配置信息(比如endpoint)，也可以不内置 而像github这种，则必须手动填写endpoint或者在后端代码中进行额外的处理

不知道我的表达是不是准确

所以我可能会放弃此次PR，对此我深表歉意。感谢您的支持和帮助

[IamTaoChen]

OIDC 应该是包含了 google ，Keycloak，Okta等等

所以我现在也是基于，我将oauth分类的，是标准OIDC还是其他的。Op只是显示名称，会在数据库中与type进行绑定。当开始认证的时候，读取Op的type然后开始使用不同的流程。

像google这种公共端点明确的，直接内置了scope和endpoint. 而像其他标准OIDC的IdP, 则只需要用户多指定issuer和scopes（一般是openid, profile,email），当然还有显示名称。

当然在处理google的时候，这个PR有些问题。我之前没主要到google v3是OIDC标准，可以进行一简化，当前是复用oidc的代码