4.登录功能架构设计(三)#

4.9 企业级单点登录设计#

大多数企业、机构都有各种各样的系统，每个系统都有各自的用户体系和登录流程，因此用户需要记忆各个系统的登录账号和密码，以及登录地址。怎样将这些孤立的系统整合起来，让用户一次登录，处处登录，让系统之间的访问既安全又便捷就是单点登录的目的。

单点登录可以通过整合用户体系、账号绑定、授权绑定等多种方式完成。

4.9.1 认识单点登录#

单点登录（Single Sign On，SSO）是一种企业级系统整合方案，目的是只需要登录一次就可以访问所有互相信任的系统。

企业发展初期一般只有一个系统，随着企业不断发展，系统不断增多，有OA系统、财务系统、决策系统、销售系统等，大型企业的系统甚至多达几百个。这些系统有的是企业在不同时期开发的，有的是从外部厂商采购的。

企业都希望用户只需要登录一次，就可以全系统通用。一个人只记住一个系统的账号、密码和地址即可，这就是所谓的单点登录模式。

实现单点登录面临的问题如下：

• 各个系统的账户体系没有统一，各自存储在自己的数据库中（可能数据库类型也不同），数据没有打通。

• 彼此之间难以建立关联关系，各个系统的登录流程各不相同，有的系统采用账号+密码登录，有的系统采用手机号+密码登录，等等。

• 用户登录成功后，无法与多个系统保持Session会话。

4.9.2 简单绑定单点登录设计#

优缺点分析：这种模式最大的优点是简单，第三方系统无须进行开发；缺点是安全性极差，相当于把账号和密码都暴露给了其他系统，并且此种模式并不适用于手机验证码、扫码登录等方式。

4.9.3 授权绑定单点登录设计#

比较安全的方式是访问令牌绑定设计，账号和密码不暴露给其他系统，而只发放凭证。

单点登录授权绑定流程如下：用户首先登录SSO系统，然后发起绑定操作。这时需要跳转到第三方系统的授权页面（此页面为被绑定系统的页面，而不能由OA系统开发，从而保证安全性）。授权页面可以为用户名密码认证、手机验证码认证、扫码认证等方式。当第三方系统登录认证成功后，会生成一串加密字符，作为系统访问凭证返回SSO系统。后续SSO系统跳转或访问其他系统时，只需要携带此凭证进行访问即可。第三方系统接收到凭证之后，验证凭证的有效性，如果凭证合法、有效则可访问。

4.10 OAuth 2.0认证授权设计#

在App端可以选择微信登录，点击“微信”图标会唤醒手机中的微信App，询问用户是否同意授权，用户点击“同意”按钮就代表授权通过，则用户的头像、性别、用户ID等信息就会授权给第三方使用，对于在Web端的微信扫码登录，原理也是相同的。

无论是授权绑定还是授权登录，本质上使用的都是OAuth 2.0协议。OAuth2.0协议是当前认证授权的行业标准，其重点在于为Web应用程序、桌面应用程序、移动设备及室内设备的授权流程提供简单的客户端开发方式。

1. OAuth 2.0协议的4种角色#

在OAuth 2.0协议中包含4种角色，它们之间相互协作才能够对系统提供安全的认证授权流程。

（1）Resource Owner（资源所有者）：是能够对受保护资源授予访问权限的实体，可以是一个用户。例如，用户把钱存在银行中，钱是资源，而用户才是资源所有者，并不是银行。

（2）Resource Server（资源服务器）：持有受保护资源，允许持有访问令牌的请求访问受保护资源。例如，对于银行或银行的管理系统来说，银行或银行的管理系统才是资源服务器，它们持有受保护资源，只有有权限的个人或银行柜员才可以操作。

（3）Client（客户端）：持有资源所有者的授权，代表资源所有者对受保护资源进行访问。例如，手机银行App，它就是客户端，它通过用户的授权代表用户对账户中的资金进行操作。

（4）Authorization Server（授权服务器）：对资源所有者的授权进行认证，成功后向客户端发放访问令牌。例如，银行的认证授权系统、账户管理系统，只有通过账号和密码的正确认证，才会允许对账户进行操作。

2. OAuth 2.0协议的工作原理#

OAuth 2.0的认证授权流程分为以下6个步骤。

（1）客户端请求资源所有者的授权。

（2）资源所有者同意授权，返回授权许可（Authorization Grant），这代表了资源所有者的授权凭证。

（3）客户端携带授权许可要求授权服务器进行认证，请求访问令牌。

（4）授权服务器对客户端进行身份验证，并认证授权许可，如果有效，则返回访问令牌。

（5）客户端携带访问令牌向资源服务器申请对受保护资源进行访问。

（6）资源服务器验证访问令牌，如果有效，则接受访问请求，返回受保护资源。

3. OAuth 2.0协议的工作流程举例#

下面以淘宝手机App为例，详细讲解OAuth 2.0协议的工作流程，首先分析出4种角色分别是谁。

（1）资源所有者：淘宝用户，拥有所有的订单、账户余额、积分等资源。

（2）资源服务器：淘宝后台系统，保护用户的资源，只允许用户本人操作这些资源。

（3）客户端：淘宝手机App，代表用户与淘宝后台系统交互。

（4）授权服务器：淘宝认证授权管理系统，用于验证用户名和密码的正确性，发放访问令牌。

4种角色的协作流程分为6个步骤，具体如下。

（1）客户端请求资源所有者授权，这时打开淘宝登录页面，淘宝要求输入用户名和密码。这个过程就是客户端（淘宝手机App）请求资源所有者（用户）授权（输入用户名和密码）。

（2）资源所有者同意授权，即用户录入了用户名和密码，并且点击“登录”按钮，表示同意了授权。把个人许可（用户名和密码）交给了客户端。

（3）客户端携带个人许可去请求授权服务器认证，即携带着用户名和密码去请求授权服务器验证用户名和密码是否匹配。

（4）授权服务器验证用户名和密码是否正确，如果正确，则返回访问令牌；如果不正确，则拒绝授权。

（5）此时用户成功登录，去查看自己的订单，则携带访问令牌去请求淘宝后端服务。

（6）资源服务器验证令牌有效性，如果有效，则返回用户的订单信息。

4. OAuth 2.0协议的4种模式#

OAuth 2.0协议共有4种常用模式：授权码模式、简化模式、密码模式和客户端模式，安全性依次从高到低。

（1）授权码模式。

一般的第三方账号登录，如QQ登录、微信登录、微博登录等都采用授权码模式实现，此种模式流程最为复杂，安全性也最高。

（2）简化模式。

简化模式只是授权码模式的一种简化。在授权码模式中，需要先获取授权码，再使用授权码去获得访问令牌。而简化模式省略了这个步骤，在用户授权后就直接将访问令牌返回给客户端，其余流程完全一致。

（3）密码模式。

密码模式是大多数系统采用的模式，用户直接在客户端页面上录入用户名和密码，由客户端携带客户端凭证（客户端标识）、用户名和密码去请求授权服务器，授权服务器验证客户端是否可信，用户名和密码是否正确；如果验证无误，则返回访问令牌，客户端携带访问令牌即可进行资源访问。

使用密码模式要求用户对客户端有足够的了解和信任，因为用户会将用户名和密码直接交给客户端，如果使用了一个假的银行软件，那么后果可想而知。所以，在密码模式中才必须携带客户端凭证，授权服务器需要确保接收的请求来自可以信任的客户端。

（4）客户端模式。

客户端模式最为简单，只需要携带客户端凭证就可以访问，如SecretID和SecretKey模式。这种模式一般只允许内网和专线访问，或者添加了访问白名单的系统使用，以及无须用户授权的开放式系统使用。互联网应用如果使用客户端模式就需要极为慎重。

4.11 用户扫码登录设计#

扫码登录是在手机普及之后才推出的一种安全又便捷的登录方式，前提是扫码应用（手机App）与需要扫码登录的系统必须使用同一套用户体系。所以，使用微信扫码登录第三方网站本质上是借助了OAuth 2.0协议中的授权码模式。第三方网站其实借用了微信的用户信息，与自己的用户信息进行了绑定。

那么，如果不使用微信而使用自己的App是如何完成扫码登录的呢？

扫码登录流程总体分为以下3个步骤。

（1）浏览器展示登录二维码，并提示用户使用指定App进行扫码登录。

（2）用户使用指定App扫描浏览器中的二维码。

（3）浏览器跳转到登录成功页面（大多数跳转到系统首页）。

4.12 章节练习#

1.在系统登录功能的设计中，有哪些安全问题是需要考虑的？#

（1）用户敏感信息和密码应该加密存储，并且防止加密后的密码被破解。使用更加安全的哈希算法、加盐、多重加密等方式。

（2）数据传输需要保证不被窃取、不被篡改，可以使用HTTPS、加密和签名等方式。

（3）用户的Session时长不能过长，避免用户忘记退出系统导致信息泄露。

（4）对于Web客户端，用户数据存储在Cookie中，需要加密存储，避免泄露和篡改。

（5）对于App客户端，用户数据存储在手机上，需要加密存储，并设置有效期。

2.单点登录是什么，为什么需要单点登录？#

单点登录（Single Sign On，SSO）是一种企业级系统整合方案，目的是只需要登录一次就可以访问所有互相信任的系统。当企业中孤立的系统众多时，用户需要逐个登录不同的系统，并且系统之间无法进行有效协作，造成工作效率降低。单点登录让用户一次登录就可以访问所有具有权限的功能。

3. OAuth 2.0协议中包含哪些角色，它们的作用是什么？#

OAuth 2.0协议包含资源所有者、资源服务器、客户端和授权服务器4个角色，作用如下。

（1）Resource Owner（资源所有者）：是能够对受保护资源授予访问权限的实体，可以是一个用户。

（2）Resource Server（资源服务器）：持有受保护资源，允许持有访问令牌的请求访问受保护资源。

（3）Client（客户端）：持有资源所有者的授权，代表资源所有者对受保护资源进行访问。

（4）Authorization Server（授权服务器）：对资源所有者的授权进行认证，成功后向客户端发放访问令牌。

4. OAuth 2.0协议共有几种常用模式，安全性如何？#

OAuth 2.0协议共有4种常用模式，即授权码模式、简化模式、密码模式和客户端模式，安全性依次从高到低，授权码模式安全性最高，客户端模式安全性最低。

5.在集群和分布式架构下使用Session会有什么问题，怎样解决？#

在集群和分布式架构下Session数据会无法共享，导致用户无法跨服务器访问资源。需要使用Session共享机制，或者将Session数据存储在Redis、MySQL等共享设备中。

6. Session同步是否能够很好地解决Session无法共享的问题？#

在服务数量较少的情况下，Session同步可以较好地解决Session共享问题。但是，当服务数量较大时，就会引发Session同步风暴，增加各个系统的存储压力和运行压力，同时稳定性较差，很可能有部分服务器无法正确同步Session数据。

7.密码、人脸识别、语音识别、指纹识别登录过程的共同点是什么？#

无论登录的形式怎样变化，都是数据采集和数据比对两个步骤。人脸识别、语音识别、指纹识别只不过是将人脸、语音、指纹转化为数据，通过各种

算法形成一个密码区间，只要用户登录时匹配度达到一定的程度就可以通过验证。

8.什么是聚合服务？#

将相同、相似的功能整合在一个服务之中，对外提供统一透明的服务能力，称为聚合服务。

短信系统实际上是依靠移动、联通、电信三大运营商的短信发送协议实现的。然而，3家公司的协议并不相同，这样使用者就需要使用不同的短信接口发送短信。而短信系统聚合服务可以将短信发送接口聚合为一个接口，自动根据手机号的号段，选择发送给哪个运营商，对于使用者完全透明，不需要了解内部的实现细节。

9. Cookie的特点是什么，有哪些注意事项？#

不同的浏览器对于Cookie的存储限制不同，大小一般要求不超过4kB，同一个域下能够存储的Cookie数量也有不同的限制，不适合存储大量信息。

Cookie存储在客户端被篡改、劫持都相对容易，所以Cookie中的内容最好进行加密存储。存储的Cookie数据不要过多，否则会发生旧的Cookie被覆盖或被删除的情况。Cookie默认是明文传输的，使用HTTPS会更加安全。

4.13 案例设计#

1.场景设计题：分布式认证中心#

某系统采用分布式架构设计，希望开发一个认证中心服务，负责以下内容。

（1）作为所有系统的认证和授权的唯一中心，将用户安全进行统一管理。

（2）系统能够对用户身份进行鉴别，同时对用户访问的资源合法性进行控制。

（3）系统能够随时将某用户踢出系统，以及冻结和解冻账户。

（4）系统能够对用户安全状况做出评估，评定级别，同时予以冻结并告警。

（5）系统本身需具有极高的高并发能力和响应速度。

如果您作为企业的系统架构师，会怎样进行系统设计，需要考虑哪些内容？

2.设计思路指引#

（1）作为用户认证中心，一定持有用户体系数据，必须能够直接访问账户数据，包括用户名、密码等。如果采用手机验证码登录，则应该可以获取短信验证码数据，从而判断用户是否为合法用户。

（2）认证中心必须掌握账户的权限配置数据，用户需要访问哪个资源（路径、接口等）必须具有明确的授权关系定义。当用户访问这个资源时，必须先请求认证中心，判断其是否具有访问权限，并返回授权结果。

（3）认证中心需认证用户是否正常登录、是否冻结、是否具有资源访问权限。

（4）对于身份认证通过的用户，应该在用户登录时颁发访问令牌，当用户访问其他系统资源时，需要先请求认证中心，验证令牌是否合法并且有效。如果令牌不存在或已过期，则不可以访问系统。

（5）认证中心应该将所有的令牌数据集中存储在缓存中，并设置有效期。当需要踢出某个用户或全部用户时，仅需清空令牌数据即可。

（6）需要冻结用户时，认证中心应该直接修改账户状态为已冻结，并且将对应的令牌数据删除，避免出现用户被冻结，但是仍然可以继续访问系统的情况。

（7）认证中心应该根据用户登录的行为（失败次数、频率、IP地址、个人定位信息等）给用户评定安全级别。如果一个用户频繁登录失败，则可标记为风险用户，并发送短信予以提醒，同时锁定用户，避免账户被盗。

（8）认证中心是所有系统认证授权的中心，访问量巨大，因此一定要采用集群方式部署，并且使用内存型数据库进行数据存储，使用关系型数据库作持久化。

（9）认证中心需要具有自己独立的管理功能，包括用户状态的管理、令牌的管理等。

（10）在微服务架构中，可以将网关和认证中心结合在一起使用。