多应用SaaS平台的授权设计面临用户归属、角色管理和权限分配的多重挑战。本文深入剖析了平台型产品（如钉钉）中用户身份唯一性识别、应用间角色隔离、权限点自主管理等核心问题，并提出了基于业务对象关系的最优解决方案。通过对比不同场景下的设计思路，为复杂SaaS系统的权限架构提供实用参考。

首先说一下，我自己做过多应用的产品开发，但是 SaaS 这块我们当时是单应用。

这里的多应用是指一个 SaaS 平台有多个相互独立的业务应用，甚至服务提供方都是不同的公司。比如，在钉钉里我们可以用很多第三方的 SaaS 软件。

在这种情况下，我们的权限设计就又多了一层，即应用。这个时候授权又该如何设计？

01 先梳理业务对象关系

这个观点前面也提到过，对于我们一时无法判定的产品设计，可以先梳理一下业务对象关系，然后再来看看怎么设计我们的产品。这里的关键其实是下面几个问题：用户（指租户侧员工）归属哪个应用？角色归属哪个应用？权限点归属哪个应用？

02 用户归属

显然，对于像钉钉这种平台型的 SaaS 产品，用户实际上是属于整个平台的，也就是用户信息是在平台侧。租户那边添加用户为员工实际上是给用户开通了该租户的数据权限。那么，如果用户属于我们自己 SaaS 租户业务系统的主应用（比如员工账号是租户业务系统添加的），这种情况下怎么操作呢？

解决问题的关键其实是身份唯一性的识别。

对于用户属于平台，因为本身用户具备了唯一标识，所以这种方式多应用的授权会更简单一些。

对于我们说的这种情况，可以有以下几种确定用户唯一性标识的方式：

手机号：大部分情况下可以解决唯一性的问题，但是如果员工手机号变更，可能会在主应用中更改，但是无法同步到其他应用（应用服务商不同，意味着数据是隔离的）。

这个时候，就需要平台开放员工同步信息功能，也就是其他应用可以经过租户管理员操作同步最新的员工信息。这种好处是，假设其他应用有自己独立的入口（比如钉钉的 Teambition、纷享销客等等），那么他可以凭借手机号登录，也能继续使用。

员工 id：相比手机号，员工 id 在主应用中不会变更，因此是绝对的唯一。

当然，同样也会存在需要同步的情况，比如员工离职、变更部门等等。这种缺点是，员工 id 依赖主应用，意味着只能通过主应用进入到其他应用。

实际上面，钉钉里的第三方应用也有同步员工信息的功能，如果管理员发现应用内的员工信息和实际不符时，是需要手动同步的。从设计上来说，显然将用户归属到平台会是更好的方式，因为这应用间的隔离程度更高。这种情况下，平台自身就需要搭建一个维护员工组织关系的模块 —— 比如钉钉的通讯录。

03 角色归属

显然，我们没法将角色统一管理，那样意味着平台要获取所有第三方应用的权限点。

一方面是这样同步会非常复杂，另一方面是意味着第三方得按照平台的规则设计开发，保证权限点的数据格式相同。

这两点都是不合理的，但是实际上我确实见过一家 SaaS平台是这么做的。他们实际上不仅提供了平台，还提供了一套技术开发框架，应用必须要按照他们的框架进行开发才能入驻到该平台。

当然，这个平台属于内部 SaaS，这种方式可以统一公司的技术栈，所以问题倒也不大。

但是，从产品和开发的角度来说，真的非常不友好。

举个典型的例子，当他们的平台框架升级时，其他应用需要同步升级，这显然是不合理的。

所以，角色我们最好是有应用自己维护，给予应用更多的灵活处置能力，甚至的小应用干脆角色管理都可以没有。

这种情况下，应用既可以入驻到平台，也可以独立自己的产品，这样才能够吸引更多的第三方应用加入到你的平台。平台不要采取捆绑的方式来绑定第三方服务商，而应该保持足够的开放性才对第三方更有吸引力。

04 权限点归属

这个毫无疑问是归应用所有的，每个应用可以按照自己的方式去定义权限点，并且通过角色来管控账号的权限。

05 业务对象关系

经过上面的论述，我们就能够得到一个最优的业务对象关系了，如下图所示。

用户归属于平台，用户不一定是某个租户的员工（如果有 toC 业务）；租户归属于平台，可以订阅多个应用。用户可以使用租户下的应用，前提是租户给员工开通应用权限，这样员工对应的用户就能够使用该应用了。

员工自然属于租户，当租户添加员工时，实际上是将用户和员工进行了关联。应用维护自身的角色和权限点，并管理应用内的授权。

租户管理员可以通过应用提供的权限管理模块来控制员工的使用权限。用户能不能用某个应用取决于两点，一是他是租户的某个员工，二是他被租户授权可以使用该应用。

06 产品设计

在上述的业务对象关系下，实际上租户侧的应用只需要做一件额外的事情，那就是同步租户的员工信息（可能包括组织架构信息），其他都不需要做任何修改。

这样的应用和我们自己基于自己的 SaaS 平台开发的租户侧业务系统几乎没什么差别。

对于平台侧而言，则是需要增加用户管理模块，这个模块中还需要维护用户与租户员工的关系。同时，还需要维护租户相关的应用信息，以便为租户的员工提供相应的应用入口。

具体这块的参考案例，建议是大家参考钉钉的设计。

07 纯内部应用设计

还有一种特殊情况，就是 SaaS 平台并不为第三方提供入驻，但是内部有产品矩阵。租户可以选择不同的产品订阅。

这种情况下，我们是可以简化设计的。也就是在授权管理时，增加应用切换功能，租户可以分应用进行授权，如下图所示。

这种情况下，我们可以对已经开通了应用权限的员工开放不同的应用入口。