登录系统演进、便捷登录设计与实现

2024-04-02
上海
本文字数：4252 字
阅读完需：约 14 分钟

作者 | 百度 APP 技术中台吧

导读
随着互联网、物联网和移动终端等技术的迅猛发展，登录认证面临着新的挑战和需求。虽然登录认证在信息系统中是传统且古老的组成部分，但未来的发展前景依然广阔。不论是用户登录、PC 端、移动端还是智能设备的访问，身份认证在保障业务操作安全、资金安全、系统间通信和与外部系统集成等多个方面起到至关重要的作用。随着认证方式的不断演进，从最初的 cookie 和 session，发展到如今的多端登录、多因子认证以及 API 令牌等多种认证手段。同时，用户终端设备的不断升级也推动着认证方式和手段的不断创新。
本文探讨登录认证技术的演进历程，并介绍在终端设备上实现便捷登录的设计与实现方法，以供各位同学参考。我们希望通过这篇分享，能够帮助读者深入了解和应用新型的登录认证技术。

全文 4467 字，预计阅读时间 12 分钟。

01 登录认证发展历史

账号系统作为一家企业的核心系统，承载着日益增长的业务需求。以百度为例，简化的结构如下：

其账号中心提供支撑服务，支持百度系内 100+业务，包括百度 APP、网盘、地图、贴吧等，具备全面的账号能力，这对账号系统提出了更高的要求和挑战，那么企业账号管理是如何一步一步发展到这一阶段，下面将分阶段简要介绍账号中心的发展过程：

1.1 单体应用时期

软件系统的建设初期，大多需求都是针对具体的领域中的业务，所以在建设过程中专注于系统业务的快速实现，对于登录认证的实现，往往都采用简单的账号密码进行登录，并在登录后返回服务器的用户数据，其交互流程如下:

在这种单一账号密码认证方式下，将用户信息存储在 Cookie 中的做法确实存在安全隐患，即使引入了 httponly、secure、samesite 等属性设置也难以完全解决泄露风险。因此，随着对安全性要求的提高，逐渐引入了 token 机制来加强认证和授权过程。

1.2 Token 验证机制

Token 机制的主要原理是在用户登录成功后，后端服务器生成一个加密的 token，并将其返回给客户端，客户端在后续的请求中将该 token 携带在请求中。这种方式可以避免暴露用户信息，同时提高了安全性：

在这个阶段，已经按照功能模块对业务进行了初步划分，即账号功能模块与其他各个功能模块解耦，实现了模块独立化。这样的设计有利于系统的可维护性、扩展性和灵活性。

1.3 多业务统一账号中心

在将单一业务拆分成多个或新业务成立时，各业务系统都需要账号登录认证能力。为了实现能力复用、专注于业务划分，并确保各系统自身业务特点的建设，设计中不入侵各系统实现认证成为必要要求。为解决这一挑战，进入多应用账号中台阶段。该阶段的关键步骤包括：

1.设计统一认证方案：制定一套统一的认证协议或标准，以确保各业务系统与认证中台之间的通信和数据交互规范。这样的设计有助于确保认证系统的稳定性和兼容性，同时简化了不同业务系统之间的集成和沟通。

2.搭建认证中心：建立独立的认证中心系统，负责统一管理用户身份、处理登录请求、颁发令牌等任务。认证中心的建立能集中处理用户身份的统一管理和认证流程，实现高效管理，为各业务系统提供稳定可靠的认证服务。

3.业务系统集成认证中心：业务系统在需要认证的场景调用认证中心提供的接口进行认证，避免自行实现认证逻辑，减少耦合。通过与认证中心进行集成，业务系统可以快速、简便地获取认证服务，大大提高了系统的可维护性和灵活性。

4.统一管理用户身份和权限：认证中心统一管理用户身份信息和权限，确保各系统之间的用户身份一致。权限变更只需在用户中心进行，无需逐个系统修改。这种集中式的用户身份和权限管理方式有助于降低系统维护成本，并简化管理流程，同时提高了系统的安全性和一致性。

通过引入中台，我们可以实现认证能力的复用，降低各业务系统间的耦合度，更专注于业务逻辑的实现，提升系统的安全性和可维护性。

1.4 外部合作 OAuth 授权

随着公司集团业务的不断拓展，与外部第三方展开合作已成为必然趋势。在授权第三方使用百度的商业服务时，可能涉及到通过百度账号授权登录外部应用程序，而这一过程通常采用 OAuth 授权流程。OAuth 是一个关于授权的开放网络标准，在全球范围内得到广泛应用，目前最新的版本是 2.0 版。

在 OAuth 的架构中，设立了一个授权层，用于在“客户端”与“服务提供商”之间进行连接。这意味着，客户端无法直接登录服务提供商，而必须通过授权层进行连接。这样一来，用户与客户端之间就得到了有效的区分。客户端登录授权层所使用的令牌（access token）与用户的密码不同。在用户登录时，可以指定授权层令牌的权限范围和有效期，以确保安全性和控制权限。

OAuth 2.0 定义了四种授权方式：

1.授权码模式（authorization code）
2. 简化模式（implicit）
3. 密码模式（resource owner password credentials）
4. 客户端模式（client credentials）

其中，授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它通过客户端的后台服务器与“服务提供商”的认证服务器进行互动，这是它的特点。

在百度 OAuth 体系中，通常遵循授权码模式。以下是一次移动端流程的简要描述（Web 流程内重定向流程有些许差异）：

1.5 统一登录分散认证阶段

面对不同产品线安全级别存在差异，以及使用相同登录凭证可能导致整个百度集团产品线受到影响的问题，这确实是一个严峻的挑战。尽管各个应用的安全等级不同，但实施时却是并行的，这意味着一旦某个应用存在安全问题，可能牵扯到整个集团的安全。

在这种情况下，为了有效控制安全风险，可以考虑在统一认证凭证 token 的基础上，根据不同业务新增 sub_token 进行区分产品认证。这种做法有以下优势：

安全隔离：通过为不同产品线新增 sub_token，可以实现对不同产品线的安全隔离。即使某个产品线的 token 泄露，攻击者也只能获取到与该产品线相关的 sub_token，而无法影响其他产品线的安全。
细粒度控制：每个 sub_token 可以针对具体的产品线或业务场景进行配置，包括权限范围、有效期等。这样可以实现对不同业务的细粒度控制，提高了安全性。
快速应对风险：当某个产品线出现安全问题时，可以快速作出响应，封禁受影响的 sub_token，从而降低了整体风险。
降低攻击影响：即使某个 sub_token 被攻击者获取，由于其仅适用于特定的产品线或业务场景，攻击者对其他产品线的影响将大大降低。

通过引入 sub_token，可以在确保统一认证凭证的基础上，进一步加强对不同产品线的安全管理和控制，有效降低了整个集团面临的安全风险。

02 便捷登录方案

随着技术的不断发展，软件功能的优化已成为行业的主要趋势。在保障安全的前提下，简化用户登录流程成为优化方向的首要任务。传统的账号密码登录方式需要用户手动输入用户名和密码，这一过程耗时且繁琐。即便是手机号短信验证码登录，用户仍需点击获取短信，查看验证码后再切回应用输入，涉及多个步骤。以下将介绍三种仅需一步操作即可完成的登录方式，以期为用户提供更便捷的体验。

2.1 运营商手机号一键登录

用户可以使用自己手机号码作为登录凭证，实现一键登录，这种登录方式通常与用户的手机号码关联，无需记忆繁琐的用户名和密码，提高了用户体验和登录效率，实现通常依赖于运营商的身份认证系统，通过向运营商发送请求等方式，验证用户 sim 卡。一旦验证通过，系统即可信任用户的手机号卡号，无需再次输入密码或其他信息。完整的一键登录设计一般为以下流程：

这种登录方式的优点包括方便快捷、安全可靠，减少了用户忘记密码或被盗号的风险。同时也降低了应用或网站的开发和维护成本，提高了用户的使用黏性和留存率。但需要注意的是，运营商手机号一键登录需要企业的系统支持用户绑定手机号，同时企业应注意用户相关隐私政策和条款，并向用户声明。

2.2 可信设备历史登录

历史账号一键登录是指用户无需重复输入账号和密码，而是通过一键点击即可完成登录操作。这种登录方式利用了用户过去登录过的账号信息，通过存储和验证机制，实现了用户登录过程的简化和加速。

用户无需反复输入账号和密码，只需点击一次即可完成登录，大大提升了登录过程的便捷性和速度。通过减少用户的操作步骤，简化了登录流程，从而提升用户的使用体验和满意度。虽然简化了登录过程，历史账号可以一键登录，但仍然需要经过安全身份验证机制，以确保用户账号的安全，例如遇到安全风险进行面部识别、双因素认证等技术手段。

2.3 人脸验证登录

顾名思义，用户使用智能设备进行人脸验证，在与底图比对验证通过后，派发账号的登录信息，这个过程有两个核心环节：①知道要派发哪个账号 ②用户的人脸底图收集。

对于环节①，一般设计都是用户主动输入自己的账号，自动触发检测当前账号是否支持人脸登录，或者使用历史登录过的账号自动触发检测，即：

而服务端检测用户账号是否支持人脸登录，一般需要用户主动开启刷脸登录方式，而在开启刷脸登录时，需要用户进行人脸验证录入底图，这样在下次使用人脸验证时，变可以使用录入的底图进行比对。当然，对于安全性要求较高的业务，可以引导用户进行实名，之后的刷脸登录访问公安网进行三要素比对（收费），而百度内部同时支持这两种流程，下面是一次完整流程：