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

2020-01-28 本文已影响0人 needrunning

一篇介绍开放平台建设文章大型互联网企业平台开放技术实践整理，原文值得收藏，多次阅读。

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

开放生态包含四个角色，开放平台，开发者（ISV），商家和用户。

image.png

ISV通过企业的开放平台可以开发出商家所需要的SAAS软件。

一个大的开放平台下，总会有许多依附于这个平台下的软件开发商，合作伙伴和自由软件者。

我找了一张阿里云合作伙伴的介绍文案如下

阿里云合作伙伴.png

开放授权是基于Oauth2.0 深入介绍的。授权和账户是紧密相连的。

文中的一张图区分几个混淆的概念，OpenID，unionID，pin

image.png

OpenId表示验证，Oauth表示授权

因此安全上的考虑，如果只是暴露OpenID和UnionID并不能对用户的数据安全造成危害，因为平台上的登录操作不需要OpenID。OpenID表示的是验证，也就是是说，该用户是不是此企业平台下的用户，是一种“是不是”的关系。

Oauth表示的是授权，是第三方开发者可不可以使用或者获取该用户下的数据，是一种“可不可以” 的关系

无论OpenID还是unionID最终都是要换成用户pin，因为底层接口业务只能识别pin，OpenID和unionID仅仅是开放场景下的用户标识

数据安全的数据归属判断

获取到资源Id之后，进行数据更新删除修改之前，做一步判断资源是否属于当前用户的操作

数据归属判断.png

接口提供方数据归属判断.png

原文中有这么一句话

开放网关的时候开放网关将accestoken置换成了pin

这句话展开来说就是，消息和数据在系统之间传递时用的是token票据，在每个服务内部交互时，使用的是用户唯一标记，比如真正的用户userId,而这个userId只要出了服务层，就不对对外暴露了，直接用token取代了。【这块是我一向的观点】

结合上一节，在开放平台接口接口设计中有两个原则

1 不直接暴露userId为业务入参

也就是说服务端在获取用户信息的方式，不能通过GET、Post参数、Header头中获取当前用户的登录信息。需要一个用户登录信息与uid的映射过程。

2 在业务逻辑层根据AccessToken 实现与用户唯一标识（uid）的互换。