本文所说的电商小程序为一个B2B2C在线蛋糕DIY平台，其主打“蛋糕在线定制”，并支持成品蛋糕的在线销售，以下简称该项目为BC。
作为一家初创公司，BC团队需要快速开发出产品原型以用来验证市场需求。而任何一个产品，为了跟踪数据，必须要有一套用户系统，这里面既包括了用户的登录、注册、第三方登录、忘记密码等琐碎功能，还包括了管理员对用户信息的管理和安全认证。如果先完成这些外围业务，必然会耽误核心业务实现。为了加快系统开发速度，减少一些不必要的开发时间，BC的创始人Steven选择了Authing云端身份认证（authing.cn）来解决这一部分需求。
以下是他的分享：
一、选择
两个月前，我在V2EX上发现了Authing这个平台。那时，我正在构思BC项目，BC这个项目有两个核心业务，一个是B2B2C的电商平台，另外一个是在线DIY蛋糕。为了能够让我们的开发人员快速进入核心业务开发，我们计划使用Authing处理身份认证。
决定使用后我就联系上了Authing的创始人，他和我们进行了深入合作。比如BC客户端是在小程序上的，那时Authing还不支持小程序，因此我们绕道小程序，使用小程序新开放的web-view完成了Authing的接入。此外，Authing还协助我们完成了数据库的设计，我们本地数据库只存储了用户的authingId和小程序传过来的用户信息。
二、挑战
这一节我想多说一些技术接入上的细节，看不懂的可以直接跳到最后。
首先从业务说起，BC是一个B2B2C的平台，意味着我们至少需要三种用户身份：
1. 买家（定制蛋糕、对蛋糕下单）
2. 卖家（管理商品数据、接单、实行配送）
3. 管理员（管理平台所有数据）
而Authing正好可以通过创建应用隔离用户数据，因此我们在Authing平台上创建了三个应用，并在程序中通过判断应用ID实现了BC系统中的权限隔离（应用的ID会附加在登录成功后的token中，可直接读取）。
自此我们解决了用户身份的问题，但是现在还不能立即接入业务，我们还需要设计数据库结构。在Authing的协助下，我们完成了三张用户表的数据库设计：
可见，我们的表结构都非常简单，完成这三张表，只花了10分钟。
在我们的开发团队写好了这三张表的增删查改和配置CORS后，我们开始正式接入Authing。
首先接入小程序。
前端使用了Authing提供的vue-demo中的代码，快速完成了一个基于web-view的认证网页。用户在第一次访问BC小程序时会先跳到这个网页进行认证（用户的微信信息通过postmessage的方式发送到认证网页上），认证网页再将用户信息发送给Authing进行认证，认证通过后即跳回小程序上，然后小程序存储Authing Token等信息完成认证（日后的每一次请求都需要发送Authing Token，然后后端验证该Token是否合法）。
整个过程花费了前端小哥2个小时的时间，当我们从测试小程序登录后发现Authing同步增加了用户数据并能看到统计后感到非常开心。
然后接入商家和管理员，我们要求商家只需使用微信扫码登录。
因为管理后台基于Web，所以直接使用Authing的JavaScript SDK即很快完成了开发。值得一说的是，在做微信扫码登录时，我们只写了客户端的登录存储代码，整个微信OAuth的开发过程极其简单。
我们仅仅在Authing的后台对微信的Client ID和Client Secrect和Redirect URL进行了配置，然后在客户端读取了“已开启”的OAuth服务，用户从扫码到登录成功后的任何操作，我们都不用操心！
三、投入生产环境
很难想象，我们在一天时间内就打通了用户流程，还拥有了一整套管理用户的GUI。第二天，我们的团队就投入到核心业务，整个过程非常顺利，两个月后我们完成了所有功能的开发、测试和运维，并将产品和Authing投入到了生产环境。
虽然Authing帮我们分担了很多工作，但Authing仍有很多功能待完善。比如应该增加用户管理的Hook功能，假如我在Authing的后台删除了一个用户，那么可以触发我的一个远程API，让我在本地数据库中也删除该用户的其它关联信息。同理，增加、修改都需要。但对于一个初创产品，Authing确实已经很好的满足了我们的需求。
我也看好Authing这种将一些基础功能基础设施化的云平台，如果追求效率，上云是个不错的选择。
中国并没经历工业化过程，从洋务运动到苏联的工业体系引进到加入WTO，所有这些技术变革都是上层引入带动，而不是像西方社会那样由资本家、发明家来推动社会生产关系变革。但是，在可预见的未来，随着金融、医疗和收入的提高，我看好中国社会未来的效率为主。
了解更多：authing.cn
Github：github.com/authing
1288
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
