开放平台技术实践-开放生态与授权服务

2020-02-20 13:45:05 浏览数 (1)

文本基于 大型互联网企业平台开放技术实践 整理,原文值得收藏,多次阅读。

文章从开放生态、开放网关、开放授权和开放安全四个方面阐述了开放平台的建设路径。

开放生态

开放生态包含四个角色,开放平台,开发者(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月 山西

0 人点赞