随着企业信息化建设的不断提高，多业务系统的统一集成逐步成为核心诉求，而打通这些系统间身份更是重要环节。即为用户和所有业务系统提供标准且便捷的身份认证机制，需要做到以下几点：

•           单点登录。对终端用户而言只需要一处登录即可访问所有业务系统，无需重复登录。

•           安全且标准的集成协议。对业务系统而言需要有标准且统一的协议规范支持身份认证集成，在安全性保障的前提下，最好做到开箱即用，减少重复开发。

浅谈单点登录原理

单点登录（Single Sign On），顾名思义：登录一次，处处通行。其核心解决许多相互关连，但是又是各自独立的软件系统，在某个系统登录成功以后，也可以正常登录其它系统，而不需要重新登录。在网页应用中，通常通过 Cookie 保存会话。基于此原理，可以通过一个独立的认证中心系统来保持全局的登录会话，所有业务系统均通过此系统的会话实现各自会话的创建和登录。

整个流程的登录关系简图如下:

从上图可见其整个单点登录流程的特点如下：

1.         用户的认证，以及业务系统登录都需要借助统一认证中心，在安全性上避免用户的敏感信息（如密码登）泄露给恶意程序。

2.         两个业务系统之间的单点是借助统一认证中心完成，而非两个系统之间直接传递已登录用户信息。统一认证中心与业务系统间通过设计好的参数完成身份数据的传递。

3.         未授权的应用无法通过统一认证获取到已经登录的用户信息。

单点登录过程的认证时序图如下，共有 3 类角色：

•           用户浏览器

•           业务系统 1 和业务系统 2

•           认证中心系统

整个流程按照如下过程进行:

1.         用户通过浏览器访问业务系统 1 时，业务系统 1 发现自身没有登录，此时跳转到认证中心要求完成登录。

2.         认证中心发现自身也没有登录，此时返回登录表单给浏览器，要求用户输入用户名密码完成验证。

3.         用户提交用户名和密码后，认证中心校验通过，则创建单点登录会话，并携带票据 1 回传到用户的浏览器中，在此响应过程中，会在浏览器中设置单点会话相关的 Cookie。

4.         票据 code 通过浏览器回传给业务系统 1，业务系统 1 根据约定完成用户认证后，建立自身会话并展示相关的表单页面。

5.         用户继续访问业务系统 2，业务系统 2 发现自身没有登录，此时同样跳转到认证中心要求完成登录。

6.         此时因为认证中心已经登录，不会要求用户重新认证，此时直接携带票据 code 回传到用户的浏览器中。

7.         票据 code 通过浏览器回传给业务系统 2，业务系统 2 根据约定完成用户认证后，建立自身会话并展示相关的表单页面。

综上基于 Cookie 单点登录的特点在于：

1.         各个业务系统及认证中心均有各自的会话，通过认证中心的会话来保持用户"已经登录"的状态。

2.         为了保证整个登录过程的安全有效，认证中心通过票据来标识用户信息并传递给业务系统，给各个业务系统读取此信息还原用户信息并创建各自会话。

以上的过程中，用户各个业务系统间识别用户的票据应该做到加密不可破解，且有效期尽可能短，避免被其他人利用。而 OAuth20 协议的授权码方式则是一种有效的实现。

OAuth20 协议

OAuth20 是行业标准的授权协议，OAuth20 为 Web 应用程序、客户端程序统一授权。传统应用间访问，需要持有用户信息甚至透传用户密码，此方案无权限控制也容易泄露用户密码等私密信息。OAuth20 协议的特点在于，通过设置中间的授权层，将用户与客户端进行了隔离，各个业务系统之间的访问持有的不再是用户的用户名或者密码，而是用户授权给指定业务系统的临时授权码和授权令牌，临时授权码和授权令牌都有时间和权限设置。

OAuth20 协议参与角色

OAuth20 涉及到的几个重要角色：

•           Resource Owner：资源所有者，可以简称为用户。

•           User Agent：用户代理，本文中就是指浏览器。

•           Authorization Server：认证服务器，处理认证的服务器。以前文单点登录流程为例，即为认证中心服务器。

•           Resource Server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。以前文单点登录流程为例，即为认证中心，其保护的资源为用户的认证信息。

•           Third-party Application：第三方应用。以前文单点登录流程为例，即为业务系统 1 和业务系统 2。

OAuth20 协议授权类型

OAuth20 针对不同客户端和场景设计了多种授权类型：

•           Authorization Code Grant

•           Implict Grant

•           Resource Owner Password Credentials Grant

•           Client Credentials Grant

Authorization Code Grant 授权码模式授权

以上授权模式中，Authorization Code Grant 授权码模式安全性更高，应用范围也更广。授权码模式下，所有的第三方应用需要在认证服务器注册自身地址，认证服务器会给这个第三方应用分配单独的 client_id 和 client_secret。

•           client_id 第三方应用标识，可以在网络中明文传输。

•           client_secret 第三方应用密钥，需要保存在第三方应用后台，避免外泄。

认证过程如下：

1.         每次第三方应用发起认证时，第三方应用拼接单点登录地址传入参数 client_id, redirect_uri, response_type。

–          client_id 用于标识第三方应用。

–          redirect_uri 回调地址。用于告诉认证中心在认证成功后，通过这个地址回传给第三方系统临时授权码。

2.         认证中心收到第三方应用的登录请求后，检验其 redirect_uri 与系统内注册的地址是否匹配，此机制限制只有在认证中心注册的应用才可以通过认证流程，结果有以下两种情况。

–          如果不匹配则终止流程。

–          如果匹配则通过 redirect_uri 回传授权码 code 给第三方应用。

3.         第三方应用获取授权码 code 后，在 Server 端调用认证中心接口，传入参数 code, client_id, client_secret 换取用户授权 access_token。

–          认证中心会对 client_id 和 client_secret 进行校验，如果参数不匹配，则第三方应用无权限调用认证接口。

–          code 通常有效期很短，且只能使用一次避免 code 的重复滥用。

–          code 只能给匹配的第三方应用使用，即业务系统 1 申请的 code 不能用于业务系统 2。进一步提升安全性。

4.         当第三方应用获取到 access_token 后，即可调用资源服务器（也可以是认证服务器）的接口验证用户信息。

浪潮海岳提供以 OAuth20 协议授权码方式支持多业务系统的单点登录和统一认证。减少了业务系统重复开发的成本，满足不同客户多场景下的应用单点登录集成。以此为基础，构建安全认证体系，支持多因子认证增强认证安全，内置认证风险控制防护，通过统一审计精确完成事后追溯。

希望今天的分享，能带给大家些许启发，也欢迎大家一起留言共建~

写在最后，欢迎大家下载我们的inBuilder开源社区版，加入我们，开启开发之旅！