开放平台技术实践-开放生态与授权服务
文本基于 大型互联网企业平台开放技术实践 整理，原文值得收藏，多次阅读。
文章从开放生态、开放网关、开放授权和开放安全四个方面阐述了开放平台的建设路径。
开放生态
开放生态包含四个角色，开放平台，开发者（ISV），商家和用户。
image.png
“ISV 通过企业的开放平台可以开发出商家所需要的 SAAS 软件。
每个大的开放平台下，总会有许多依附于这个平台下的软件开发商，合作伙伴和自由软件者。
我找了一张阿里云合作伙伴的介绍文案如下
阿里云合作伙伴.png
开放授权
开放授权是基于 OAuth2.0 深入介绍的。授权和账户是紧密相连的。
文中的一张图区分几个混淆的概念，OpenID，unionID，pin
image.png
OpenId 与 OAuth
OpenId 表示验证，Oauth 表示授权
“因此安全上的考虑，如果只是暴露 OpenID 和 UnionID 并不能对用户的数据安全造成危害，因为平台上的登录操作不需要 OpenID。OpenID 表示的是验证，也就是是说，该用户是不是此企业平台下的用户，是一种“是不是”的关系。
“OAuth 表示的是授权，是第三方开发者可不可以使用或者获取该用户下的数据，是一种“可不可以” 的关系
“无论 OpenID 还是 unionID 最终都是要换成用户 pin，因为底层接口业务只能识别 pin，OpenID 和 unionID 仅仅是开放场景下的用户标识
开放安全
数据归属判断
数据安全的数据归属判断
获取到资源 Id 之后，进行数据更新删除修改之前，做一步判断资源是否属于当前用户的操作
数据归属判断.png
token 与 pin 的互换
接口提供方数据归属判断.png
原文中有这么一句话
“开放网关的时候开放网关将 accestoken 置换成了 pin
这句话展开来说，消息及数据在系统之间传递时用的是 token 票据，过了网关，在每个服务内部交互时，使用的是 用户唯一标记。
userId 只要出了服务层，就不对外暴露，直接用 token 取代。【这块是我一向的观点】
总结
结合所述，坐一个小结，在开放平台接口设计中有两个原则可以参考
1 不直接暴露 userId 为业务入参
也就是说服务端在获取用户信息的方式，不能通过 GET、Post 参数、Header 头中获取当前用户的登录信息。需要一个用户登录信息与 uid 的映射过程。
2 在业务逻辑层根据 AccessToken 实现与用户唯一标识（uid）的互换。
推荐本文和 系统服务化构建-两方OAuth 和 退出功能需要网络支持吗？两篇文章一起阅读，应该会有更多收获。
end2020年1月 山西