Authorization Server、Resource Server and Wechat‘s Authorization Flow

导读

如果外部IDP是符合 OAuth2、OpenId 或者 SAML 等标准协议的授权服务器的话，我们可以直接使用标准的方式对接外部IDP。但是由于微信提供的 Web 授权方式不完全符合 OAuth2 协议，小程序的方式更是没有标准协议对标，就没有办法按照标准的方式对接了，但是幸好 OAuth2 协议提供了 Password 的方式。

Authorization Flow

开发者服务器中存储的user password 和 client secret 是双向加密的

刷新token的话由开发者服务器作为代理刷新，前端传递 client_id 和 refresh token；这里有个疑问就是 client_id 和 refresh token 都在前端，那么恶意用户只要获取到了这两个值，那么就可以无限续杯了，这样会不会增加安全风险？我认为是不会的，因为 access token 同样存储在前端，恶意用户可以获取存储到前端的 client_id 和 refresh token ，同样也可以获取到一直有效的 access token。

Authorization Server 上用户信息的合并。假设同一个组织运营的多个公众号，没有绑定到了同一个开放平台上，这时对于一个用户来说，他针对每个公众号都有一个openid。这时，如果一个用户访问了公众号A的业务系统，在A的业务系统里面有一条用户记录，在 UAA 中创建了一个影子用户；然后此用户又访问了公众号 B 的业务系统，此时在B的业务系统里面有一条记录，在UAA中也创建了一个影子用户；这时，在UAA中针对此用户就存在了两条用户记录，不管怎样，这不是我们想要的结果。
这个问题的解决方案貌似就是特定事件时合并用户的信息，比如说用户在A公众号的业务系统中绑定了手机号，在B公众号的业务系统中绑定手机号时，系统就需要能够判断出这是一个人，要进行合并账号了；
由于在A业务系统和B业务系统中使用的都是自己系统中用户表的id或者当前业务的标识，所以如果合并账号之后，只需要修改A系统和B系统里用户表的uaa user的标识即可，所以 Authorization Sever 合并账号的行为在业务系统中成本极低；
在UAA中合并账号，主要牵扯到 users + userinfo 表的合并和group的合并；
如果有冲突的话，需要记录下来，并且在业务系统中引导用户再次确认使用冲突中的那一方的数据；
比如A系统对应的 UAA 中的影子用户和 B 系统对应的 UAA 中的影子用户都有 email ，并且不一样。那么这个冲突就需要记下俩，在A或者B的业务系统中，引导用户再次确认是使用哪个email。比如告诉用户部分信息过期；或者一个引导用户补充信息的活动，填写email，发送领虚拟币的链接；或者显眼位置展示冲突一方的数据，引导用户去修改，如果修改了，使用修改后的值，如果没有修改，那大概率就是当前显示的值，多次之后也可以将当前展示冲突的一方作为用户的最新信息，等等的策略。

上面合并用户的情况，很少会有组织遇到这种问题，大部分情况下，抽取数据，在另外一个离线系统中做用户画像，就足够了。
因为两个系统，基本上不太可能有业务重叠，没有必要在两个不同的业务系统中识别出跟另一个不相关的系统中的某个用户是同一个人。

往 UAA 里写入影子用户需要带 scim.write 或者 uaa.admin scope的 access_token

id,uaa_user_name,RSA(uaa_user_password),phoneNumber,additional_information
id,uaa_user_name,RSA(uaa_user_password),member_openid,unionid,additional_information
id,uaa_user_name,RSA(uaa_user_password),other_openid,unionid,additional_information
id,uaa_user_name,RSA(uaa_user_password),email,additional_information
id,app,client_id , RSA(client_secert)(这就相当于配置到sso应用上的clientid和clientsecret)，其他信息，比如微信H5网页里的redirect url等；