Auth的那些事儿

来TW的4年了，一直没有换项目，也一直更客户构建一个auth中心，以供客户那边的所有产品服务。 4年来，风风火火，集成了很多系统，也陪走了很多团队。有一天碰到一个之前合作的同事说，你咋还在这个项目，这项目咋还没做完？嗯 ～～。

对啊，不就是个auth，简单的登录，几个页面，还集成了现成的IDP，做了4年还没有做完。为了证明我们没有摸鱼，有必要说说我们这些年为了auth，到底做了什么。

作为公司内部的项目，一开始，其实我们是并没有太多明确的需求的，我们都知道要做什么，但是具体都做什么，还不清楚。我们要做出个产品，然后在公司内部推销，让其他产品觉得好之后，丢弃他们现有的auth，跟我们集成。因此，我们也认为auth，不就是给个用户名密码，然后返回一个凭证（token）。顺便加上忘记密码，和用户注册三个页面解决了吗？也对，不够的话就再加个API版的。公司这边使用的都是AWS， 因此，我们选择了AWS Cognito userpool作为IDP, 几个月的功夫，我们的产品上线，第一个新客户快速集成，反馈不错。

上线了之后，我们趁着这股劲就去谈了公司使用用户基数最大的产品（几百万用户），他们也愿意跟我们集成（其实是公司的策略）。果然是大客户产品，一上来几个问题就抛了出来：安全，性能，集成和迁移, 数据同步和传输。还好，基于AWS这个大树，最终我们搭建了数据安全传输通道和性能测试环境， 开启了多因子验证，基于事件的同步机制，用户迁移和集成，及用户基本信息管理平台。

随着越来越多产品的加入，需求不停的增加。产品要加强brand信息，所有的页面和通知都要根据不同的client定制内容和样式。甚至流程的定制化，比如有客户涉及到付款，不能满足于只在登录时多因子验证（MFA），因此我们开发了in-app challenge，允许客户端按需在任何过程中对用户发起验证。对客户的定制化还体现在了流行的social登录中。这里有个核心的问题是email相同的用户要不要合并账号，不同的客户对此要求不一样。很长的时间我们都在解决social登录的问题。

光说产品好不行，还得有良好的开发集成体验，毕竟我们产品的用户是跟我们集成的产品的开发人员。所以还要编写对应的SDK（包括mobile）和使用样本例子供客户快速集成，同时也开通了在线服务随时解答客户的问题。还少不了客户关注的各种监控和统计数据图表。

这么多，够了吗？显然不够，上面的这些，主要核心解决了用户与产品之前的认证问题，但是在微服务的环境下，服务与服务之间的认证，是不是也要提供一下。为了不跟用户认证扯一起，我们单独开发了service到service之间的认证。

以上这些都是我们做的关于AuthN的东西，但是auth 还有另外一个大头就是authZ，虽然不是一回事儿，但是很多客户认为就是一回事儿，所以我们也得管。因为我们为了适应大多数客户的需求，开发了一套基于ABAC协议的AuthZ产品，这部分这里就不阐述了，详情在我另外一篇博客.

其实刚上项目的时候，我也问过这样的问题，“这就个auth，有啥做的，会不会很快就结项了”。真是 “too young, too simple, sometimes naive”。到今天，项目依然继续，我们仍然在路上。同时也给想要做auth服务的你，给个参考，这坑不简单，甚至很好玩。