前不久我与售前同事聊天，他们反馈说很多客户在前期了解产品的时候，都会问这样一个问题「你们的 FinClip 支持与我们自己的用户体系打通吗？」

实际上这确实也是老生常谈的问题，随着公司规模越来越大，员工需要使用的产品矩阵也会越来越丰富，不仅包括内部的 IT 系统，OA 系统，业务系统，还会有很多和外部产品集成的登录流程，更别提各种业务系统或者子系统中的账户体系了。如果使用简单粗暴的方法，让员工在每一个系统中单独注册一个独立的账户，不仅员工的用户体验简单粗暴，也会陡然提升员工密码管理的相关成本。

在开始本篇文章之前，我想先与大家聊聊，什么是账户体系认证。

什么是账户体系认证？

不论是在哪个产品中登录自己的账户，你可能都需要通过输入自己的手机号，用户名，邮箱或者工号的方式登录到这个产品之中（扫码其实也是一种方式）。但是在这个过程中我们为什么需要输入自己的相关信息呢？

其实在这个过程中我们主要是为了解决以下三个问题：

这三个问题是非常重要的，因为他们构成了在账户体系中身份认证和授权的基础要素，我们先尝试来分别解答这三个问题：

1. 我是谁？

这个问题关注的是用户或系统的身份标识。在一个服务端账户体系中，你需要确保每个用户或系统都有一个唯一的标识符，通常是用户名、电子邮件地址、用户 ID 或其他独一无二的信息。这个标识符用于识别和区分不同的实体。身份验证的第一步就是验证这个标识符是否有效，并确定它对应的用户或系统。

2. 我有什么权限？

这个问题涉及到用户或系统被授予了什么操作或资源访问权限。权限可以分为多个级别，从只读权限到完全控制权限等。在服务端的账户体系中，通常会使用角色（roles）或权限组（permission groups）来管理权限。用户或系统被分配到一个或多个角色或组，每个角色或组都定义了一组具体的权限。确保在身份验证后，根据用户或系统的角色或组确定其可访问的资源和执行的操作。

3. 我属于什么组织？

这个问题关注的是用户或系统的组织隶属关系。在许多应用中，用户可能属于一个或多个组织，这些组织可以是公司、团队、部门等等。组织通常用于管理资源的访问和共享，以及确定用户在组织内的角色和权限。确保你的账户体系可以处理多个组织和用户在这些组织之间的关系，以便正确授权和限制资源访问。

如何对齐管理后台中的账户体系？

我们处理账户体系的主要任务是确保系统中的账户、角色权限、组织等信息与需要集成的系统中的相关字段能够协同工作，以实现身份验证和授权功能。业界中已经有非常专业的问题解决思路了，比如这几种方法：

1. 单点登录 SSO

SSO 是一种常见的解决方案，允许用户在多个系统之间使用单一的身份验证凭据进行登录。通过使用标准协议（例如 OAuth、SAML、OpenID Connect 等），我们就可以将账户体系与需要集成的系统相连。在连接完毕之后，一旦用户登录了一个系统，他们就可以无需重新登录访问其他系统。

2. API 集成

我们也可以设计一组 API，用于管理用户、角色、权限和组织等相关信息。这些 API 可以用于创建、更新、删除用户帐户、分配角色、分配权限以及管理组织结构。其他系统可以通过调用这些 API 来实现与账户体系的互操作。

3. 数据同步映射

有些特殊的系统可能会存在一些当前业务中所需要的业务字段，因此我们还需要考虑通过数据同步和字段映射可以用来维护不同系统之间的一致性。通过定期同步用户、角色、权限和组织等数据，确保它们在不同系统中保持一致。当然，数据同步的前提是我们需要根据定义字段映射规则，以确保不同系统中的数据可以正确匹配。

4. 中心化人员管理

如果可能的话，我们也能够尝试去建立一个中心化的身份管理系统，这个系统负责管理所有用户、角色和权限。其他系统可以与这个中心化系统进行集成，以便统一管理身份信息。这种方式可以减少数据不一致性的问题，并简化维护。

当然，不论我们最终选择了哪一种账户体系对齐的方法，都需要考虑能够在与自有业务体系集成以外，提供足够的代码与业务审计机制，以便用于应付后续可能的审计与日志留存能力，万一在出现任何异常或未经授权访问时查证对应的问题。

FinClip__43">FinClip 的管理后台账户对齐方式

正如同上文所说，我们在向一些私有化客户提供相关服务时，会分别采用“数据同步”或“实时校验”的方式解决账户体系对齐。当然由于不同客户的业务环境与内部业务水平不一，我们也分别整理出了两种方式的优势，以及需要考虑的相关风险。

方案一：数据同步

这种方式需要客户基于 FinClip 提供的 OpenAPI 与相关服务，将对应的账户信息同步在我们所提供的服务之中，最终通过统一的账户体系完成账户鉴权与登录操作。

这种方式具有这些优势：

• 较好的性能与时间优势：数据已经同步到了 FinClip 服务中，在实际使用和查询时的耗时较少，效率较高；
• 离线支持：数据已经同步到了 FinClip 服务中，即使客户的账户对接系统失效，最终用户也依然可以完成操作与访问请求；
• 减轻集成方负担：客户只需要定期同步数据，不再需要考虑实时请求；

当然，采用这种方式我们也需要考虑这些风险：

• 数据同步可能延迟：数据同步可能会有一定的延迟，在某些情况下可能不会立即反映出最新的账户信息；
• 需要定期同步保证数据一致：需要定期同步和更新数据以确保一致性，但可能会引入一些同步问题；
• 可能存在安全性风险：在数据同步期间，账户信息可能会存在风险，需要确保数据的保密性和完整性。

方案二：实时校验

这种方式需要 FinClip 通过客户提供的账户接口完成账户校验的相关工作，在获得账号相关信息后完成登录。

这种方式具有这些优势：

• 实时性较高：FinClip 能够随时请求到最新的账户信息，保证了较高的实时性；
• 精确控制：在具体业务中可以精确地请求和获取账户中的相关信息，而不是对整个数据内容进行同步；
• 降低数据冗余：FinClip 中不再需要单独存储账户中的相关字段数据，减少了数据冗余和一致性的相关问题；

当然，选择这种方式我们也需要考虑这些风险：

• 性能和响应时间不确定：实时校验可能导致延迟，特别是在高负载情况下或者集成方的系统响应较慢时；
• 对客户集成系统的依赖较高：服务高度依赖于集成方的稳定性和性能，如果集成方出现故障或者延迟，可能会影响到 FinClip 的服务和相关能力；
• 可能需要频繁调用：如果需要频繁访问账户信息，可能会导致过多的请求，增加了集成方的负担。

总的来说，选择哪种方式取决于客户自有业务或 IT 系统中的需求和系统架构。假如说对实时性要求较高，就可以考虑“方案一，实时校验”。如果性能和可用性更重要，或者需要处理大量数据，“方案二，数据同步”可能更合适。

当然，在我们的实际经验中，也发现有一些客户没有选择标准协议进行对接，而是基于自有的业务场景和能力封装了一套“非标账户协议”。但不论选择标准协议还是非标准协议，这里的对接思路都差不多，即：

标准协议对接：

1、拿到 accountID 唯一标识（基于 OAuth/SAML/OIDC 对接）
2、用户登录：基于标准协议进行用户身份校验后登录
3、用户角色：基于预先配置获得用户角色，用户可以自行修改/账户集成系统中自带角色管理能力

非标协议对接：

1、通过 token/账密/客户使用 API 先行创建接口
2、用户登录：基于对应参数进行用户身份校验后登录
3、用户角色：基于预先配置获得用户角色，用户可以自行修改/账户集成系统中自带角色管理能力

通常，在实际应用中，可以综合考虑两种方式的优缺点，或者根据不同的用例选择不同的集成方式。最重要的是确保数据的一致性、安全性和可用性。

FinClip__94">FinClip 的小程序账户对齐方式

在我们聊完了管理后台中的账户对齐方式后，也不妨来聊聊在“小程序业务”中，用户账户对齐的常见问题吧。

由于小程序大多时候都会作为某个宿主 App（或设备） 中的功能模块存在，因此在小程序中的登录方式一般都会基于宿主 App（或设备） 中的账户进行修改，并不会在小程序中再次出现和 App 中一模一样的登录页面。

在我们熟知的微信小程序中，一般会在小程序端调用 wx.login 获取用户 code，然后再通过服务端验证的方式调用。

在 FinClip的场景中我们也提供了丰富且灵活的用户授权方式供不同类型的开发者选择，不论哪种开发者都能够基于 FinClip 获得灵活的小程序账户对齐能力。

方案一：服务端改造

服务端改造的使用场景主要是“客户基于 FinClip 打造自有小程序生态，但无法具备小程序的代码管控的相关能力”，在这种情况下使用服务端改造的方式较为适宜。

在这种情况下，客户需要在以下环节中投入相关的改造成本：

• 第一步：在 App 中通过自定义 API 注入 wx.login 方法，按照微信小程序的格式返回 code；
• 第二步：小程序无需改动，按照在微信端的实现，此时会将 code 发送给开发者的服务器；
• 第三步：开发者服务器进行适配，通过 code 可判断登录来自 FinClip 平台，从 code 中解析出 UserID，返回自身账户体系的内容即可。

方案二：服务端改造+微信授权

服务端改造与微信授权集成的场景主要适用于“客户通过 FinClip 完成原有 App 中相关功能的拆分。实际工作过程中所有的小程序都是由自有研发团队进行修改与集成的。”

在这种情况下，客户需要在以下环节中投入相关的改造成本：

• 第一步：SDK 中集成微信开发平台 SDK；
• 第二步：使用自定义 API 注入 wx.login，唤起微信授权后即可取得返回 code，此时可能需要对 code 拼接唯一标识；
• 第三步：小程序无需改动，按照在微信端的实现，此时会将 code 发送给开发者的服务器；
• 第四步：服务端根据 code 唯一标识，调用不同的授权接口取得 OpenID，查询登录态返回；

请注意由于微信限制不同主体，不同开放平台下的 OpenID 是不一致的，此时小程序需要关联到同一主体，或者同一开放平台（此时唯一标识为 UnionID）。

方案三：小程序改造

小程序改造的使用场景主要是客户目前已经有可用于生产环境中的小程序，但需要对小程序中的内容进行逻辑修改，增加环境变量的方式（比如通过 wx.login 或类似 wx.loginFinClip 之类的自定义 API）进行判断（当然，这种情况下也需要具备小程序代码编辑的能力）。

这种情况下，主要需要在自有 App 中通过自定义 API 注入 wx.login 来获得当前用户的登录态。