现代身份的挑战无处不在，软件/应用作为数字化的载体，不可避免的会涉及到身份。

想象一个场景，你正在开启一个新的软件/在线应用项目，然后你花了大量的时间研究需求、推演方案，设计算法和功能。当你完成了这一系列工作，已经准备好把你关于项目的所有想法付诸实践时。突然你意识这个软件/应用程序需要有身份管理的功能，这时必不可少的你就需要开始考虑用户系统的设计。于是，您开始研究如何创建帐户。刚开始，你可能认为这就是个用户名和密码校验的工作，但是你慢慢的发现，为了更好的引入用户，可能需要社交登录；为了验证用户的安全性需要提供多因素身份验证；为了更好的营销需要引入更多的用户信息，你可能采用的微服务的架构，可能需要服务之间的认证；不同用户拥有不同的权限这时需要基于身份的授权；为了更好的用户体验，需要以上所有这些用户的设计能够跨多个设备使用，等等。这时你才会发现自己在和一个多头的妖怪在战斗，当你解决一个头以后，不断又有新的头冒出来，让你疲于和它战斗，而让你的项目和想法迟滞。如果没有一个很好的计划来处理身份管理，那么解决一个身份管理挑战可能会导致更多的挑战。

身份挑战

虽然身份管理在理论上是一个简单的概念，但要使其在实践中如何让身份成为一个支撑而不是一个负担，需要多种因素共同作用。提供良好的用户体验是基础的要求，还需要平衡来自业务需求和安全性的无数期望。因此，身份需要仔细的规划、设计和开发来实现对正在进行的项目提供的良好支撑。不幸的是，身份管理没有一个一刀切的方案，我们没有办法能够构建的一个完美的解决方案适合每一个场景和用例。

举个例子来说，下面是您可能需要考虑的许多不同挑战中的一小部分。

面向消费者和员工的身份需求截然不同

面向消费者的场景：这种场景下应用程序的用户可能希望能够使用微信这样的社交提供商快速登录。他们甚至可能希望能够使用多个社交提供商登录到您的应用程序，并且仍然被识别为同一个人。您就需要优雅地处理这样的需求，否则用户可能会在注册过程中放弃该应用的申请，因为注册和登录很麻烦。

面向员工的场景：员工用户需要通过其工作帐户访问公司应用程序，他们希望通过单点登录来实现应用访问便利性。更重要的是，公司组织通常具有复杂的授权管理需求（通常基于角色或者有层级的部门），以管理组织中员工可以执行的操作的权限。具有敏感内容的应用程序可能需要除了密码认证方式之外的更强大的身份验证形式。这就需要确定哪些身份验证形式提供了足够的安全性，并且仍然方便用户的使用。比如，强身份验证有许多选项，从设备上生成的一次性密码、到短信的推送通知，或者使用私有加密密钥的硬件安全令牌。您需要易于用户采用和使用的解决方案，如果不当选择，有可能因为繁琐的解决方案导致用户绕过解决方案或干脆完全放弃使用该应用程序。

不同类型客户端的程序要求不同的登录方式

如果企业当中，为员工提供了多个应用程序，这种情况下，除了您的应用程序之外还提供了一个支持门户，那么您的用户可能需要单次登录，这样他们就可以登录一次并访问多个应用程序。这为用户提供了便利，也为控制身份验证策略提供了独立的位置。但是，身份验证应用程序的网关必须是高度可用的，并且需要比应用程序具有更高的伸缩性；否则，它将成为一个障碍，而不是一个门户。您的身份的设计可能需要适应不同平台的应用的各种约束。在Web上，用户可能希望浏览器重定向到登录页以进行身份验证。如果是本机桌面应用程序，用户可能更喜欢嵌入到应用程序中或利用底层操作系统提供的会话的登录流。如果是移动应用程序，登录方式可能又是一个新的场景，有些可能会将您重定向到身份提供程序以进行登录，但有些可能仍会直接在应用程序中提示您输入凭据。你需要权衡不同的方法和方法，为应用程序设计不同的用户体验。应用程序的身份管理设计需要回答所有这些问题以及更多问题，同时考虑到应用程序的敏感性并满足所有相关的业务需求。

错误的身份系统设计会对用户的体验带来极为负面影响：

举个例子来说，如果你注册了一个文档管理的应用程序来管理日常的文档，该程序要求扫描你的身份证和上传你的自拍视频来验证身份，才能使用这个应用。这就非常的奇怪，你可能会质疑为什么文档应用程序需要您的身份证信息才能使用。这种极端的糟糕注册和登录体验，支持会影响应用程序的转化率。当然这是一种极端的情况，但是事实上就是有很对应用，在注册/登录时需要繁琐的步骤，或者经常性的调整认证方式，而流失掉很多用户，这种现象并不少见。

另一方面，对于金融业务申请而言，提供必要的身份证信息进行身份验证就更为合理，可能受到监管要求的，在办理某些金融业务时必须提供个人相关的信息才能使用。比如，在申请贷款额度的过程中，监管要求申请人需要录制一段视频来验证申请人的身份。

一个文档管理应用程序，采用无摩擦的社交登录可能是完美的解决方案；但如果是构建一个银行应用程序，则需要更复杂的注册过程、身份验证以及强身份验证的设计。应用程序的身份管理解决方案必须与应用程序的敏感度和类型相匹配。

身份除了业务需求还需要满足合规需要

构建应用程序时的另一个主要关注点是管理敏感身份数据处理和隐私保护的法规。欧盟的GDPR（General Data Privacy Regulation）、中国的数据安全法等法规以及其他地方正在颁布的类似法规的出台，对于收集或处理用户数据的应用程序要求越来越严格，必须符合隐私要求，因为如果违反这些要求，可能会招致严厉的处罚。对于应用程序设计身份管理需要考虑的环节也越来越多。

目标

我们写这本书的目的是介绍如何做好身份管理，这些主要根据我们构建和部署应用程序的经验，以及结合目前主流的市场上的解决方案而来。本书重点是软件应用程序的身份管理方面，如创建帐户、身份验证、API授权、单点登录、帐户管理和注销用户。

对于本书的期望

身份管理是一个巨大的课题，一本书不能使你成为专家或者涵盖一切。本书讨论的身份协议规范总共超过800页，但它们也只是身份管理的一些底层基础协议。本书涵盖也无法涵盖这些协议的每个方面、细节，以及每个身份管理的用例。我们所能做的是，提供一个介绍性概述，提炼出身份管理中的一些基础的模块，对于身份协议中典型的流程、概念进行介绍，以及结合一些典型应用场景去进一步阐述三个标准协议的用法。

本文介绍三种流行的身份协议包括OAuth2.0、OIDC和SAML2.0 ，具体来说，会介绍这三种协议要解决什么问题，它们是如何工作的。基于标准的流程，是如何利用他们来实现简单情况下的身份验证和授权请求。本文不能覆盖每个参数或用例，但通过介绍，您应该对每个协议的功能和工作方式有一个基本的了解。

我们也希望您能受到启发，进一步探索身份主题，了解更高级的用例和解决方案。适当设计的身份管理解决方案可以简化您的总体体系结构，它允许您的应用程序将某些职责委派给其他组件，并且可以提供一个统一视角的用户视图，统一访问控制以简化访问控制的问题，提供关键的审核功能，等等。

阅读建议

本书将按照以下结构展开，身份的生命周期，身份的标准和演进的历史，身份的案例。关于身份的生命周期，我们对身份相关的事件进行抽象，会涉及到账户配置\初始化、用户的权限分配（授权）、用户的认证、授权的执行。

帐户配置\初始化章节，会介绍用户的初始化工作，如何引入用户到你的应用，以便他们后续使用您的应用程序；然后，关于身份的标准和演进历史，我们主要介绍目前流行的三种协议，即OAuth2.0、OpenID Connect（OIDC）和Security Assertion Markup Language（SAML）2.0。这些章节涵盖了验证用户和处理应用程序和API的授权，以及API的安全的相关模型。

有了以上的基础之后，本书提供一个示例程序以及如何使用这些协议，对以上的基础理论近一步的阐述。

在此之后的章节将介绍用户第一次登录后发生的事情，包括有关会话、单点登录、增强的身份验证形式、帐户管理、注销和取消设置等。如果您的应用程序第一次不能完美地工作，我们包含了一章关于故障排除的指导。我们还分享了可能出现的问题场景的信息，以及我们遇到的一些不寻常的用例。最后，我们简要介绍了法规遵从性以及导致一些非常不幸的违规行为的一些错误。

术语

我们讨论的协议都使用了不同的术语。不同的协议对于术语有不同的定义，这使得很难对某些组件使用一致的术语。最终我们采用的方式是，在特定协议的章节中，我们使用该协议使用的特定术语。而在其他章节中，我们将使用更通用的术语。例如，在OAuth2.0这一章中，我们提到了授权服务器；在OIDC这一章中，OpenID提供者；在SAML 2.0章节，身份提供者。在其他更一般的章节中，我们使用术语IdP 身份提供者来对用户进行身份验证。

协议	术语	中文
OAuth2.0	Authorization Server	授权服务器-IdP
OIDC	Openid Provider	OpenID提供者-IdP
SAML	IdP	身份提供者-IdP
OAuth2.0	RO（Resource Owner）	资源所有者-用户
OIDC	EU （End User）	终端用户-用户
SAML	User	用户-用户
OAuth2.0	Client	客户端-应用程序
OIDC	Relying Party	依赖方-应用程序
SAML	Service Provider	服务提供方-应用程序

在我们的术语中，客户端应用程序是一个例外。跨这些协议的客户端有许多名称 – 客户端、依赖方、服务提供商、客户应用程序。客户和依赖方在某些规范中的含义是不同的。为了方便理解，我们选择在整个过程中使用术语“application”，即应用程序，以指通过OAuth 2.0、OIDC或SAML 2.0发出身份验证或API授权请求的应用程序。我们也将终端用户简单的称为用户，因为我们不需要区分不同类型的用户。

示例程序

为了更好的说明，我们将提供了一个使用OIDC和OAuth2.0协议的示例应用程序。通过示例，介绍身份协议是如何使用的。

在开始阅读本文或者开始设计身份系统之前，我们建议考虑以下问题，带着这些问题或许对于后续章节要解决的问题有更深入的理解：

问题设计

• 身份的需要包含哪些类型用户：员工、客户、合作伙伴；
• 他们的身份标识是一个或者是多个，如何关联和映射；
• 不同身份标识对应的认证方式和可信源是什么；
• 通过何种应用进行接入，是web、API、还是native app；
• 如果进行服务的访问控制，是否需要根据以上给予不同的授权；
• 是否需要增强的身份，给予的认证有效期；
• 多个应用之间的认证是否共享，即SSO；
• 多个应用之间的身份是否关联等等
• 否涉及到敏感信息的操作，如有是否符合了法规；
• 当用户登出式，会发生哪些事件；
• 需要满足哪些合规性的需求。

本章关键点回顾

现代用户希望在使用应用程序时获得无摩擦、设计良好的体验。身份管理应该帮助他们快速访问应用程序，而不是妨碍他们。为了实现这一点，开发人员面临许多问题，需要在开发身份管理时对各种可用选项进行规划。下一章将帮助您了解身份管理的组件， 通过覆盖身份生命周期的事件来解决问题。

身份管理对现代应用程序的开发人员提出了许多挑战。

•身份管理解决方案必须与应用的类型、面向的用户体验和安全合规性要求相匹配。

•身份管理是一个庞大的主题，一本书并无法覆盖所有的范围 。

•本书将为提供身份管理概述、身份管理的涵盖范围、典型设计规范。

•介绍三种协议 – 它们的用途、工作方式以及如何进行基本的身份验证或授权请求。

•用户第一次登录后的一些其他需要考虑的环节。

•提供示例程序，说明以上所讨论的一些主题。