借auth2.0讨论互联网开发,开放,多平台间合作的鉴权逻辑

理解auth 2.0 
* OAuth 2.0 的一个简单解释

* OAuth 2.0 的四种方式 

    解读业界开放协议

          1. AUTHORIZATION_CODE和openUid是通过web返回的,也没有租户私密id.( 其实可以更进一步,可以借鉴支付的方式,服务端将信息加密后传递给B帐号,B网站需要公钥,私钥的保存,这样authorityCode安全性就等同与access_token了,关联在某个租户id上) 2. authorityCode可以关联到指定的接口和数据. 这一步是用户授权看自己要授权哪些数据.

    2.因为现有authorityCode没那么安全,所以需要通过服务端的再次请求获取一个access_token,

* 微信开放平台开发——网页微信扫码登录（OAuth2.0）

    解读微信oauth最佳实践:

       微信的oauth相比业界oatuth协议多一点,再获取AUTHORIZATION_CODE的时候就需要设置scope,让用户明确知道我授权的是哪些数据.  钉钉目前对isv的授权是笼统的,一次性.后续通过接口线下人工审批来限定.

* 另外一种更方便的授权模式 微信小程序之授权登录

笔者的解读:

   1. 授权其实无处不在. 业界的oAtuh的authorityCode其实是全局数据的开放. access_token只是临时获取某个scope的数据.但微信实践时在authorityCode获取阶段就已经限制了scope. 
   2. 开放的本质就是要解决开发一套授权的可配置,面向开发者的平台.
   3. 平台和平台之间合作,如何做开放?

       一种方式是A平台封装B平台的所有接口. 这样工作量很大,需要封装所有接口.还不能泛化调用,因为对方的设备uid没有规范化. A平台没有办法把验证过的devUid传递给B平台. 会导致1用户操作了2用户的数据, 且这两份数据都是A平台存在B平台的. 

        另外一种方式是 授权模式. 把1用户把数据授权给 isv1, 通过 isv1直接调用