The full text is 8000 words, the estimated reading time is 18 minutes

I. Introduction

Baidu ToB vertical account authority platform (hereinafter referred to as the platform) is a basic platform that focuses on providing general account authority services for Baidu ToB vertical product lines. The services provided cover tenant management, account management, single sign-on, permissions Management and control, account security, and corporate qualifications. The business side can focus on its own business research and development after hosting the account and permission-related services to the platform. At present, more than 10 million enterprise accounts have been connected to the product lines of Aifanfan, Aibuu, Xunkebao, and Chuhaiyi, providing one-stop account and permission solutions for various ToB vertical businesses. The following is a simplified version The business architecture diagram of:

△ Platform business architecture

The necessary terminology explanations are listed below for a better understanding of the content of this article:

2. Account login service

2.1 Enterprise Organization and Account Model

=================

The platform supports a customer to register multiple tenants in multiple product lines, and the data between tenants is isolated from each other. Each tenant creates a master account by default with the maximum super administrator authority, and generates a tenant organizational structure tree with jurisdictional relationship. The main account can create multiple sub-accounts, and each account can be bound to multiple third-party accounts or the customer's own account system (such as WeChat, mobile phone number, Apple account, UC, passport, etc.), and the super administrator can assign each account Assign different roles to have different functional permissions, such as assigning customer service front-line roles to customer service personnel with IM communication permissions.

△Enterprise organization and account model

2.2 Stable, efficient and configurable unified login service

ToB vertical business scenarios not only need to support Saas-type business, but also support the privatized deployment of major customers. In terms of design goals, the platform's account login service needs to provide a safe, stable, efficient and configurable for various businesses. unified login service.

△Login service architecture diagram

As a login service for enterprise applications, in order to ensure the security of enterprise users, many security policies have been added to the design of the process, so the overall login process will be more complicated:

首先以账号密码登录为例，当用户进入爱番番的页面的时候，系统页面进行初始化，此时给当前的页面生成一套独有的加密信息和时长。这里加密信息会用于后续用户填写账号、密码等信息的传输过程当中的加密；时长是当前页面的时长，如果用户在当前页面静止的时间超过系统规定的时间，那么页面信息将会失效，系统会重新加载页面。当用户填写账号、密码、验证码等信息的时候，传输给系统一串加密信息，系统会在页面最开始加密生成的加密信息当中找到密钥，并进行解密，等完成基本的账号密码信息的校验后，会经过一系列的安全策略，比如非常用地登录、常用设备检查、手机验证检查等等。安全策略通过后会生成临时验证信息返回给前端，前端在进行校验的时候，系统会将临时的登录信息替换成真实的登录信息，从而系统完成了一次登录行为。

△账号密码详细流程图

那么作为 saas 服务的统一业务基础，我们需要在登录服务上解决几个问题：

如何支持登录服务可配置化？可配置化能力可以支持不同的企业在私有化部署的场景可以按照企业自身的业务来定制登录流程，也可以支持爱番番 saas 服务接入不同的产品线的定制化需求。
如何支持多产品线应用接入并支持单点登录？
如何保障账号登录安全？登录服务的核心就是保证登录功能的安全性，作为爱番番、爱采购等系统的一级服务，防止系统被恶意入侵，登录流程的安全性就变得非常的重要。

2.2.1 配置扩展能力

一个复杂的问题通常是有多个小问题组合起来，而处理一个复杂问题也会涉及到多个不同的处理步骤，只需要采用分而治之的方式，将复杂的处理逻辑拆分出不同的小的步骤，这样可以将问题简单化。所以核心的处理思路也是将登录流程不同的处理步骤拆分出来，将步骤对应行为和操作。这样就可以得到多个不同的原子行为，而每一种行为对应不同的原子操作。

2.2.1.1 模型抽象

基于该思想可以抽象出一套模型，如下图，爱番番账号体系是可以支持多产品线的接入的，一个产品线归属多个账号。P 代表产品线，U 表示账号，E 代表登录服务的一些原子事件，C 代表登录相关的配置，S 代表登录相关的安全策略。一个产品线下可以组装不同的登录流程需要的原子事件，所以 P 和 E 的关系是一对多的情况。产品线 P 也可以有不同的配置，比如登录态时长、是否支持多端同时登录、登录端的个数等等配置。无论是产品线或者账号都会有一系列的安全策略的配置，当然这些安全策略可以是账号粒度也可以产品线粒度，比如对于一些黑产账号、异常登录行为账号的封禁策略，判断账号是否在常用地登录的提示策略等等。

△配置扩展能力图1

通过将登录过程的步骤进行拆分，由不同产品线进行组织步骤可以实现企业的一些自定义的需求，但是如何支持不同的登录方式进行可配置操作？登录服务需要支持不同的登录方式，如密保手机登录、扫码登录、第三方登录等等主流通用的登录方式，在设计可配置流程的时候需要确保设计的通用性，将不同的登录方式的登录流程也能套用一套模型当中。抽象模型 M，表示登录方式，M 也是由不同的事件组成，而产品线P是可以自定义自己的产品需要哪些登录方式的，通过前端登录组件进行展示。当然为了考虑到安全性等方面的可配置，也设置了黑名单、白名单。黑名单可以基于账号级别的一些封禁，也可以基于异常 ip、手机号等进行封禁，而白名单往往和安全策略相关，比如一些跨域请求、跳转请求等等。下图就是基于上述一些考虑丰富后的登录服务配置扩展能力抽象模型。

△配置扩展能力图2

2.2.1.2 统一登录流程

基于设计的配置扩展的能力，可以将最开始的账号密码登录流程抽象成如下的登录可配置流程图，首先采用通用的加解密服务对请求的参数进行加密处理，然后各类的原子事件和对应的原子事件处理器都注册到中央处理器当中，通过中央处理器来进行组装流程，中央处理器会通过产品线和登录方式来查询数据库配置的事件编号顺序，然后逐步触发执行触发。

△统一登录流程图

2.2.2 单点登录

2.2.2.1 流程介绍

单点登录，一般应用于多个应用系统中，用户只需要登录一次就可以访问互相信任的应用系统。比如访问 a.baidu.com , 当登录之后，再次访问 b.baidu.com、http://a.aifanfan… 都是可以免登录进行系统当中，用户只需一次登录，各个系统即可感知该用户已经登录。

△单点登录对比图

基于上述对于单点登录的说明，可以想到只需要不同端认可一份登录认证凭据就可以实现，由于 http 是无状态的，自然可以想到 cookie 用于传递不同端的用户信息，但是由于 cookie 和域是强相关性，且基于浏览器有丢失的问题，所有在不同的端互通登录态使用 cookie 存在两个问题：一是跨域问题；二是 cookie 丢失问题。平台基于 CAS 协议设计实现一整套基于多端的单点登录流程，不但可以基于浏览器解决 cookie 问题，并且支持 native 各应用之间登录互通。

如下图是平台账号单点登录的主要流程图，在系统 A 使用 ToB 账号登录的时候，登录成功后，认证中心会生成一个临时认证信息 Stoken，并且会写入认证中心的域名 www.b.com 下 cookie 当中 Ptoken，当系统成功跳转系统当中，业务A服务端网关集成登录校验 SDK，由登录校验 SDK 将临时认证信息 Stoken 换取系统 A 的真实稳定的登录态，生成只属于系统 A 的登录校验 Atoken；当系统 A 跳转到系统 B 的时候，系统 B 服务端登录态校验发现当前域名下并没有登录信息，会执行 302 跳转到认证中心，由认证中心查找域名 www.b.com 下 cookie 当中Ptoken，通过认证后，会给系统B的请求接口返回临时 Stoken，由登录校验 SDK将临时认证信息 Stoken 换取系统B的真实稳定的登录态 Btoken。所以不同系统去认证信息的时候只需要关心系统本身域名存放的信息即可，如果登录校验失败或者 cookie 丢失的场景，会跳转到认证中心再次进行校验。

△单点登录流程

2.2.2.2 认证逻辑

在流程介绍当中可以了解到单点登录当中设计了三种票据 Stoken、Ptoken、Rtoken ：

Stoken : 服务临时 token，由认证中心去颁布；
Ptoken : 存放在认证中心服务端，会请求通过 Cookie 或者 Header 的 Key 值找到相对于的 Ptoken，从而拿到用户信息；
Rtoken : 业务方专属的 token，用于当前系统的登录态校验。

生成Stoken

临时 Stoken 生成的时机有两种，一种是不同系统互相跳转的时候生成，一种就是登录的时候生成。不管哪种场景都是由认证中心去颁布，临时 Stoken 对应服务端存储的数据结构需要包含当前登录的账户信息、校验信息、客户端信息、加密信息。在设计上是一种 Hash 的结构方式，临时 Stoken 存储各类的信息保持 key-value 的方式，这样读取、存储都清晰方便。当业务系统设置登录完成跳转后的地址是 a.baidu.con/index ，那么生成临时 Stoken 后，登录服务 SDK 会将 Stoken 追加到跳转地址上，变成 a.baidu.con/index?st=xx… ,由于临时 Stoken 暴露在 url 上，为了保证安全性，临时 Stoken 的有效期设置 30s 以内，如果 30s 当中，临时 token 没有被业务请求进行认证，则直接进行销毁。

Stoken换取Rtoken

当业务 A 登录后，业务请求经过登录 SDK 校验的时候，会拿到请求参数上的Stoken，通过解密到真实存储的 Key，拿到当前登录的账户信息、校验信息、客户端信息、加密信息，生成稳定 Rtoken，将 Stoken 的信息复制到 Rtoken，并通过产品线的配置设置登录态时间。这一步就是临时 Stoken 换取真实登录态Rtoken。

校验登录态过程

△登录态校验示意图

2.2.3 登录安全性保障

2.2.3.1 分阶段session控制

通过之前的登录流程可配置、单点登录流程的介绍，在实际处理过程当中，将服务器的 session 划分成三个部分，分别是登录时期的 session、临时 session、登录态 session 。登录时期的 session 控制总体登录流程的时间，防止恶意狂刷，这种的 session 时长要设置分钟级别，如果 session 过期，需要前端登录 SDK 重新加载初始化页面信息，重新开始登录流程；临时 session 就是为了单点登录设计，这种 session 时长设置秒级别；真实登录态 session 为用户最终的登录session，存在真实的登录 Token 信息，通过不断的交互 session 来保证登录流程的安全性。如下是账号密码登录划分图。

△分阶段session划分

2.2.3.2 敏感信息加解密

加解密过程在登录流程比较重要，也是为了安全性，将具体的加密算法进行替换。这里面使用对称加密算法 A 、非对称算法 B，账号密码加密算法 C、D 等。

△加解密流程图

加解密过程如下：

首先通过加密算法A生成一对秘钥对，将公钥给端上使用，端上随机数 Random 结合公钥算法 A 加密当前随机数 Random 传给登录服务。
首先 Random 将解密出来，然后生成新的密钥对，然后将私钥，公钥存放 session 里面，并返回算法 B 加密后的公钥，这个公钥的 salt 是解出来的原始的 Random 参数。
端上算法 B 解密后出真实的公钥后。将密码算法 A 加密。
密码校验的时候，会在 session 里面取之前存的私钥，解出原始密码，再通过算法 C、D 加密后和数据库比对。

2.2.3.3 其他安全举措

cookie属性

Secure：安全性，指定 Cookie 是否只能通过 https 协议访问，一般的 Cookie 使用 HTTP 协议即可访问，如果设置了 Secure（没有值），则只有当使用 https协议连接时 cookie 才可以被页面访问。

HttpOnly：如果在 Cookie 中设置了 " HttpOnly " 属性，那么通过程序 ( JS 脚本、Apple t等 ) 将无法读取到 Cookie 信息，防止 xss 攻击。

时长：设置有效期，建议设置时长不宜过大。

请求校验

域请求限制：登录相关的接口支持跨域的场景，但是需要校验请求头 origin 属性，设置白名单，只有在登录认证中心配置的来源 origin 才可以放行；对一些执行 302 跳转的请求，同样设置白名单的控制跳转请求。

频次：登录相关的请求会根据当前的 IP、浏览器唯一 ID、客户端设备 ID 等信息设置时间范围内频率的限制，如果超过阈值，会进行频次报警，也会对指定的 IP、设备、账号进行及时的封禁。

验证码

验证码是非常有必要的，而验证码的目的就是区分正常人和机器的操作。验证码的作用在于区分人和机器，防止被暴力破解，提高破解密码的难度。只是不同阶段表现形式不同，未来的趋势是更加智能无感知，用户体验更好。登录服务支持图片验证码、人机交互滑动验证码、手机验证码。业务方可以根据安全要求不同接入不同的验证码的方式。

2.3 OAuth能力

2.3.1 OAuth介绍

ToB 多租户账号服务支持客户相关需求，有时候会和外部企业进行合作，需要保证客户体验的一致性，打通外部平台和账号系统的账号授权关系，保证登录爱番番系统的客户可以免登录到外部系统。因此需要形成一套完善的授权体系。OAuth 2.0 是目前最流行的授权机制，用来授权第三方应用,获取用户数据。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（ token ），用来代替密码，供第三方应用使用。

2.3.2 授权流程

在用户授权登录已接入 OAuth2.0 的第三方应用后，第三方可以获取到用户的接口调用凭证（ access_token ），通过 access_token 可以进行对外提供的OpenApi 接口进行调用，从而可实现获取爱番番账号用户基本开放信息和帮助用户实现基础开放功能等。目前平台 Oauth 能力支持 authorization_code 模式，该模式整体流程为：

第三方发起授权登录请求，当查询相关应用注册到授权中心的时候，如果用户没有在账号系统进行登录，会默认链接到提供的统一授权登录页，登录完成后会拉起应用或重定向到第三方网站，并且带上授权临时票据 code 参数；
通过 code 参数加上 AppID 和 AppSecret 等，通过 API换取access_token；
通过 access_token 进行接口调用，获取用户基本数据资源或帮助用户实现基本操作。

△OAuth时序图

三、权限服务

作为 ToB SAAS 产品的基础权限服务，服务于多个产品线，需要为来自各行各业的客户解决复杂多变的权限管控需求，提供包含功能权限和数据权限管控的能力。

3.1 问题与思路

问题1：各产品线在代码中实现复杂权限控制逻辑，业务权限理解成本高、维护成本高；

解决思路：提供易于接入的可扩展的功能鉴权、数据鉴权能力；

问题2：权限逻辑复杂、性能要求高，随着业务发展和客户量的增加，系统不稳定风险高；

解决思路：建设高性能高可靠的鉴权服务；

3.2 复杂的功能鉴权

3.2.1 权限接入方式

如下图所示，权限服务包含登录态校验、权限校验能力，并提供三种鉴权接入方式，分别为：

①、通过网关统一集成鉴权sdk实现鉴权，包含登录态的校验、权限校验；

②、不经过网关，单独引入鉴权sdk实现鉴权；

③、直接通过RPC接口与权限平台交互，实现鉴权；

_△___功能鉴权交互图

功能鉴权包含两部分，分别为升级版RBAC模型即 TD-RBAC、权益包模型，下面分别进行介绍。

3.2.2 GD-RBAC模型（引入用户组的基于维度和角色的权限访问控制模型）

3.2.2.1 RBAC

在介绍GD-RBAC之前，先介绍下基础的RBAC模型，Role Based Access Control，基于角色的权限控制模型的核心是在用户和权限之间引入了角色的概念。避免用户和权限的直接关联，通过用户关联角色、角色关联权限的方法来间接地赋予用户权限，从而达到用户和权限解耦的目的。

RBAC模型模型是20世纪90年代研究出来的一种新模型，RBAC认为权限授权的过程可以抽象地概括为：Who是否可以对What进行How的访问操作，并对这个逻辑表达式进行判断是否为True的求解过程，也即是将权限问题转换为What、How的问题，Who、What、How构成了访问权限三元组。即在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离，极大地方便了权限的管理。

用户（User）：每个用户都有唯一的UID识别，并被授予不同的角色；
角色（Role）：是一种虚拟身份，关联一组权限，必须关联到某个用户身份才能使用；
资源（Resource）：资源是用户与系统交互的对象实体的一种抽象；
功能（Function）：某个业务功能，通常是多个接口地址组成，比如打开某个菜单页面、按钮是否可见等操作；
权限（Auth）：角色和功能之间的关联映射；

_△___RBAC模型

RBAC 支持三个著名的安全原则：最小权限原则、责任分离原则和数据抽象原则

最小权限原则：RBAC 可以将角色配置成其完成任务所需的最小权限集合；
责任分离原则：可以通过调用相互独立互斥的角色来共同完成敏感的任务；
数据抽象原则：可以通过权限的抽象来体现；

3.2.2.2 GD-RBAC

上面介绍了基础的 RBAC 模型，但随着业务发展，无法满足不同产品线的复杂鉴权需求，比如爱番番转化提升域需要实现同一个账号在不同线索池下拥有不同的操作权限，基于此我们提供 GD-RBAC 模型：

GD-RBAC 模型是在 RBAC 基础上进行提升，具体升级点为：

1、增加用户组，多个用户（可以为1个）可以聚合为一个用户组，同一用户组内的用户角色相同，进而具备相同的权限，可以简化用户配置流程；

2、在用户组与角色之间增加维度，同一个用户组可以关联 ≥ 1 个维度，在每个维度下可以单独关联唯一的角色，进而实现同一用户在不同业务场景下的不同权限；

_△___GD-RBAC模型

GD-RBAC 示例

有了 GD-RBAC 模型，我们就可以很简单的实现用户在不同线索池下的权限配置，如下图所示：

同一个账号可以关联到不同的维度即线索池，然后每个线索池可以关联不同的角色，从而可以帮助业务实现复杂的业务定制鉴权。

_△___GD-RBAC模型在线索池业务的应用

3.2.3 权益包模型

有了 GD-RBAC 是不是就能实现所有功能权限管控了呢？仍然存在以下问题：

①、版本差异：爱番番存在多个售卖版本，比如线索管家基础版、拓客标准版、拓客专业版、私有部署版，版本之间的权限范围是不一致的，那么GD-RBAC下的不同租户的同一个超级管理员角色对应的权限必然是不相同的，举例来说基础版的管理员角色是不具备标准版管理员的潜客定投权限的；

②、功能增购：同一个用户同一个版本，用户可以单独购买产品实现功能增购，此时即使没有升级版本但权限也得到了扩充；

为了解决上述问题，我们设计了权益包模型来定义权限集合，如下所示：

_△___权益包模型

权益包是可定制的业务属性，租户可以关联多个权益包，比如爱番番产品线存在租户版本权益包、400 电话功能权益包、用户坐席 license 权益包等分类。通过租户关联权益包来实现租户权限的最大集合。通过权益包模型可以很灵活、简单的解决上述提到的三个问题：

①、租户版本权益包解决版本差异：比如租户版本权益包可以分别定义不同版本的最大功能集合，用户购买不同版本即具备了权益包的所有权限；

②、功能权益包解决功能增购问题：将不同产品功能打包成单独的功能权益，用户通过购买功能实现权限的升级。

3.2.4 功能鉴权：GD-RBAC模型 + 权益包模型

以上我们介绍了 GD-RBAC 实现通过角色来关联不同的权限，通过权益包来关联最大权限集合，那么用户的最终权限等于两者权限交集，即如下所示：

_△___完整的功能鉴权

3.2.5 快速应用：客服代操作

基于 GD-RBAC 和权益包模型，平台可以快速支持业务各种权限使用场景，这里举例客服代操作场景：

先说下代操作的概念：一组用户可以访问、操作另一组用户拥有的资源。典型例子：具有管辖权限的客服使用客服账号进入客户的爱番番系统，帮助客户完成系统配置。

客服 A 如果需要使用客服自己的账号进入张三的系统，通过设置组织结构树具备管辖权限并加入张三所在用户组，然后就可以实现客服的登录态且具备客户张三的操作权限。

_△___通过模型快速支持客服代操作业务

3.3 灵活扩展的数据鉴权

除了以上我们介绍了功能鉴权之外，不同产品线有比较灵活的数据鉴权需求，比如不同部门、职位的账号如何实现数据权限的隔离或管辖？如何构建可定制的数据鉴权能力？我们定义了用户特征，分为通用特征和自定义特征：

通用的维度特征诸如维度、产品线、行业等每个 ToB 产品都具备的，我们通过维度来实现通用特征，比如每个部门、岗位都是不同的维度。业务方可以通过维度模型规范用户数据，支持特征级联，构建用户的特征网络，从而支持不同业务自定义不同的用户特征模型；

自定义特征是通过k-v形式存储的关键值对，用于灵活定义业务数据，比如客户来源、地址等非通用数据。

_△___数据权限抽象

_△___数据维度模型

我们把维度通过左右值树结构进行存储，使得维度具有一定层次关系，如果把数据绑定在维度节点上，资源间也有了层级关系，很适合解决一些具有层级关系的权限问题。比如业务方管理员可以定义组织结构、职位两个不同的维度，来分别建立组织结构树、职位树，如下图所示：

_△___左右值树在组织结构与职位的应用示例

那么为什么要采用左右值树存储维度呢？先介绍下左右值树基本原理：

使用左右序号对每一个节点进行标记，根节点的左值是树的最小序号，根节点的右值是树的最大序号，且高度是0。

查询某节点的所有后代节点：任意节点，其后代的左值一定比当前节点左值大，后代的右值一定比当前节点右值小
查询某个节点的祖先：任意节点，其祖先的左值一定比当前节点左值小，其祖先的右值一定比当前节点右值大
计算节点下有多少子节点：包含自身：（右值 - 左值 + 1）/ 2；不含自身：（右值 - 左值 - 1）/ 2
节点排序：根据叶子结点排序。

下图是将维度1-组织结构通过左右值树进行标记的图，其中 lv 表示树的层高，lleft 表示左边序号，lright 表示右边序号，通过左右值树进行存储标记，查找用户挂在哪个维度节点上，查询效率高。

_△___左右值树节点排序

最终我们可以通过两个维度节点的交集查询得到账号张三所在部门、职位的管辖结果集：

_△___维度管辖交集计算

Therefore, through the characteristics of the left and right value tree, for the data scene with more search and less write, all child nodes of the node can be quickly obtained, and then the jurisdiction relationship can be obtained efficiently to determine the data authority.

3.4 High-performance and high-availability authentication service

As shown in the figure below, the platform caches account and permission data in BDRP, and prioritizes the judgment of permissions through the cache. At the same time, the platform is deployed in Suzhou, Beijing, and Guangzhou for remote disaster recovery. The gateway service eliminates unavailable instances through load balancing strategies and health checks; the gateway and platform can ensure continuous 2 years through multi-level back-end caching, downgrading DB and flow control fuse. Maintain 99.999% service stability.

_ △___ Multi-level cache and fuse

4. Summary

This article mainly introduces the account login service of Baidu ToB vertical account authority platform and the design of the authority service:

Through configurable event orchestration, it flexibly supports the rich login methods and login strategies of each product line, introduces the design and practice of single sign-on in detail, and ensures the security and reliability of login services through staged session control and various means;
Combined with an example, it completely introduces the functional authentication of complex services through GD-RBAC and the equity package model, and flexibly implements data authority governance through multi-dimensional authentication, helping businesses and customers to complete authority management and control simply and conveniently.

In the future, the platform will continue to enrich the capabilities of accounts and permissions, continue to improve service stability, and adhere to the concept of "technology as product service" to provide one-stop account and permission solutions to help ToB's vertical business lines better leverage their business product value .

5. Introduction of the author

This article is jointly written by a number of students from the Baidu MEG ToB vertical class Aipan Luban team:

Corwin: Senior R&D engineer, responsible for multiple business directions, good at platform and business system architecture design, using technology to solve business pain points;
Tao: Senior R&D engineer, responsible for business foundation, operation support and other related businesses, good at distributed and system design.

Recommended reading :

Input Visualization Methods in Visual Transformer

In-depth understanding of WKWebView (rendering) - DOM tree construction

In-depth understanding of WKWebView (Introduction) - WebKit source code debugging and analysis

GDP Streaming RPC Design

Decoding optimization in Baidu APP video playback

Design and practice of Baidu ToB vertical account authority platform