身份生命周期的第一步是配置身份。如第2章中所定义的，身份标识包括至少一个标识符和各种附加的用户属性。帐户是身份在特定应用中的本地构造，与标识符相关联，可用于访问受保护的联机资源。配置阶段的目标是创建或选择用户帐户和身份信息的存储库，这些信息将用于用户访问受保护资源时的身份验证和授权。
4.1身份供给方式
对于应用程序开发人员来说，身份供给阶段包括获取用户并为他们创建帐户和身份配置文件。通常，最简单的理解是让用户注册应用程序的帐户，但这不是唯一的选择。正对不同的场景，身份供给的常用方式包括：
- 用户通过注册填写信息登记表单来创建新身份。
- 特定用户通过注册邀请来填写账户注册表单。
- 从以前存在的用户存储库转化而来。
- 管理员或自动化进程创建用户身份信息。
- 利用具有现有用户标识存储库的身份服务。
这些方法不是相互排斥的；在某些情况下，多种方法的结合可能最有效。我们将更详细地描述每种方法，以及每种方法的优缺点。
自注册
用户自己注册是面向消费者的网站/应用的常用方法。它让用户为您的应用程序创建一个新帐户，并通过自助注册过程中的表单填写其身份信息。这需要通过营销推广让用户访问你的网站/应用，让他们填写一份登记表单，然后存储收集到的信息。这需要您设计和创建注册表单。为了满足合规需要，它还需要关于您正在收集的信息的隐私声明，获得用户对计划使用所收集信息的同意。您应该尽量减少所需的信息，因为如果需要太多数据，用户可能会放弃注册过程！
通过自注册表单，您可以控制用户注册体验。您可以自定义收集的信息，并直接向用户询问其他地方可能不存在的信息。自注册比管理员创建帐户更具可伸缩性。另一方面，还开展了实施和维护登记表的工作，以及获取用户同意进行数据收集和处理的程序。此外，必须填写注册表可能会阻止一些用户注册。
表 4-1总结了使用登记表的一些优点和缺点。
| 优点 | 缺点 |
|---|---|
| 能够收集其他地方不存在的用户属性。 | 一些潜在的新的用户不愿意填写注册信息，可能会影响新用户的注册。 |
| 可以控制用户注册体验。 | 承担存储登录凭据相关的责任。 |
| 通过自助服务实现可扩展性。 |
表4-1 用户自注册
渐进式注册
为了改善用户的体验，提升推广的转化，我们需要尽可能的减少用户注册需要填写的信息。您可以通过使用渐进式的信息登记来减少用户在注册时必须输入的信息，渐进式注册是一种随着时间推移为标识建立用户属性的做法，而不是一次请求所有属性。使用这种方式，用户在首次注册时会被要求提供最少的属性。如果用户稍后执行需要更多信息的事务，则会在此时收集该事务需要的用户属性。或者，在经过一定的时间或一定的登录次数之后，可以收集额外的信息。渐进式的登记减少了冗长的初始注册表单所带来的注册摩擦。它通常与自注册一起使用，但也可以与其他配置选项一起使用。
邀请注册流程
邀请注册流程是自助服务注册方法的流程之一。在此场景中，将邀请特定用户注册,邀请可以是已经注册的用户或者是管理员。
- 在面向消费者的场景比如，一些社交网站使用这种方式让用户邀请他们的朋友加入网站，被邀请的用户会得到一个链接，将他们带到一个注册表单，在那里他们可以注册。邀请可能有助于邀请特定用户测试早期访问（alpha） 应用程序或版本的版本。
- 面向员工场景邀请也可能由网站管理员触发，这种情况可能涉及用户的注册表单。如果管理员已经提供了所需的所有帐户数据，则可能只涉及电子邮件地址验证和/或密码重置。
使用“仅邀请”注册时，只能由收到邀请的选定用户组访问注册表。邀请可以通过电子邮件或短信等渠道发送，并包含允许用户注册的链接。注册页面可以将电子邮件地址、电话号码锁定为邀请中使用的地址或电话号码，以便在注册时无法更改，防止未邀请的人窃取他人的邀请并以自己的身份注册。如果需要，邀请中的链接也可以有一个与之相关联的过期时间，并且每个邀请通常都会被跟踪，因此只能使用一次。
仅邀请流程还可用于需要创建帐户以便在发送邀请之前为其分配权限的情况。此方法可用于为新员工建立员工帐户或为访问早期访问（alpha）应用程序环境建立客户帐户。管理员或自动化进程可以创建帐户，为其分配权限，然后触发向新用户发送邀请链接。用户单击该链接，并在需要时在注册表中提供其他信息。用户输入的信息可以与以前创建的帐户相关联。然后，该帐户就可以供用户使用，并且具有管理员先前分配给该帐户的权限。
仅邀请流程与前面描述的自注册选项具有类似的考虑。它还可以防止黑客和机器人的注册，当然，除非他们想办法骗取邀请！邀请注册流显然需要额外的工作来实现邀请机制以及访问控制来限制对邀请分发的访问。它可能需要管理员的工作来发出邀请或创建一个自动化的过程来完成。
邀请注册方法的一些优点和缺点如表所示 4-2.
| 优点 | 缺点 |
|---|---|
| 能够收集其他地方不存在的用户属性。 | 一些潜在的新的用户不愿意填写注册信息，可能会影响新用户的注册 |
| 控制用户注册体验。 | 承担存储登录凭据相关的责任。 |
| 通过自助服务实现可扩展性。 | 需要额外设计发出邀请的工作。 |
| 防止黑客和机器人注册。 | 对于邀请链接和控制其访问的额外开发工作。 |
表4-2 邀请注册
身份迁移
如果标识已经存在于其他位置，则可以将它们从一个存储库（如遗留数据库）移动到新应用程序可以使用的另一个存储库。这样做的好处是，用户不必提供他们在其他地方已经输入的信息，而且新的存储库可以由遗留存储库中的用户快速填充。虽然大多数用户配置文件属性都可以提取和移动，但密码是一个挑战。
密码通常以散列格式存储，散列将它们转换为一个随机字符串 字符，这不能反转以获得原始的“明文”值。每次用户登录并输入密码时，都会对其进行哈希运算，并将哈希值与用户注册或上次重置密码时哈希运算和存储的密码进行比较。以散列格式存储密码允许验证输入的密码，但会阻止具有密码存储库访问权限的管理员看到明文密码。
散列密码有不同的算法，传递给散列算法的输入也不同，例如salt和迭代计数。因此，在一个系统中散列的密码不一定能被另一个系统导入和使用。如果两个不同的系统使用不同的散列算法或同一算法的不同输入，则不可能将散列密码从一个系统移动到另一个系统并使其可供新系统使用。在这种情况下，有几种解决办法考虑迁移身份 一个新的系统。
支持遗留系统哈希算法
一种解决方案是更新新系统以支持遗留系统使用的哈希算法。这需要在新系统中实现遗留系统的哈希算法，以及确定每个帐户使用哪个哈希算法的方法。这将允许将所有身份数据和散列密码从旧系统移动到新系统，而无需用户重置密码。表 4-3总结了支持传统哈希算法的一些优点和缺点。
| 优点 | 缺点 |
|---|---|
| 无需重新设置密码。 | 实施遗留哈希算法。 |
| 以可用状态转移所有帐户。 | 承担存储登录凭据相关的责任。 |
| 继承与遗留哈希算法相关的缺点。 |
表4-3 全部迁移
批量密码重置
另一个解决方案是从遗留系统中提取用户的身份数据（不包含散列密码），然后将其导入新系统。然后，新系统需要向每个用户发送一个唯一的密码重置链接，以便为他们在新系统中的帐户建立一个新密码。这要求遗留系统中的身份信息包括一个经过验证的电子邮件地址，并且通过电子邮件发送的密码重置链接对于新系统处理的信息的敏感性来说是足够安全的。如果使用电子邮件以外的其他通信方式， 同样的验证和安全要求也适用。 应该提前通知用户有关迁移的信息，这样他们就知道需要密码重置消息，而不是将其视为试图进行的网络钓鱼攻击！如果强制用户重置密码是可以接受的，那么可以一次完成批量密码重置，这样就可以在迁移之后关闭遗留系统。
表 4-4总结了批量转移用户的一些优点和缺点。
| 优点 | 缺点 |
|---|---|
| 一次传输所有用户。 | 需要转移所有帐户，即使是非活动帐户，除非在转移过程中过滤掉它们。 |
| 支持立即关闭旧用户存储库。 | 要求所有用户通过帐户恢复设置新密码，除非新系统可以支持旧的哈希密码。 |
| 在登录时无需去就系统验证，降低验证凭据带来的延迟。 | 需要缜密的规划，否则如果迁移出现问题且没有备份计划，可能会导致大范围的中断。 |
| 传输身份的代码可以独立于应用程序代码。 | 承担与存储登录凭据相关的责任。 |
表4-4 批量迁移但不包含密码
逐步迁移用户
批量密码重置之外，可以改进的是使用热更新的机制，在用户登录时逐渐迁移身份。这需要一种登录机制，该机制提示用户输入凭据，根据旧存储库对其进行验证，如果验证通过，则从旧存储库检索身份信息，并将其和输入的凭据存储在新存储库中。在对遗留系统进行验证之后，用户输入的密码由新系统使用其哈希算法进行哈希运算，并存储在用户的新帐户中。这种方式将仅迁移登录并要求新系统验证的用户（事实上，新系统在迁移之前仍然访问旧系统并验证输入的凭证和检索用户身份信息）。这对用户来说更方便，因为不需要重置密码，但这意味着在迁移标识之前，遗留系统必须保持可操作性。此解决方案不会转移非活动帐户 (未登录的用户）。
使用渐进迁移方法，一部分用户可能在迁移期间并没有登录，因此无法迁移其身份信息。您可以设置迁移的截止日期，并决定如何处理在该日期之前尚未迁移的任何标识。一种可能是宣布未迁移的帐户处于非活动状态，并放弃它们。一种常见的方法是使用批量移动非活动帐户（不包含散列的密码），如上一小节描述，这样就可以解除旧系统的运行。如果不迁移所有剩余的标识，则应考虑保留未迁移标识的帐户标识符，以防止将来新帐户使用它们。
对于身份尚未迁移的用户，可以使用新系统输入电子邮件并获得密码重置令牌或链接。用户将确认收到电子邮件，并提示输入新密码。新系统将为新系统中的用户创建一个帐户，其中包含从旧系统中检索到的具有匹配电子邮件地址的帐户的信息。活动标识的逐步迁移，再加上剩余身份的大量迁移和凭证重置，为活跃用户提供了一种良好的用户体验，同时不放弃不经常的用户。表 4-5总结了逐步迁移的一些优点和缺点。
| 优点 | 缺点 |
|---|---|
| 不活跃的帐户可以剔除。 | 要求可以从新应用程序的身份验证机制访问旧标识存储。在传输足够的标识之前，旧标识存储必须保持可访问性。 |
| 无需重置密码 (对于在迁移期间登录的用户）。 | 在逐步迁移的过程中，必须保持迁移机制。 |
| 通过逐步迁移身份分散停机风险（无大面积故障风险）。 | 因为身份数据需要从遗留系统读取，用户在迁移开始后的首次登录可能会有一些延迟。 |
| 可以支持在渐进迁移期间继续使用以前的注册机制或使用遗留标识存储库的应用程序。 | 需要额外的开发实现 |
| 承担存储登录凭据相关的责任。 |
表4-5 逐步迁移
管理员创建
创建帐户和身份需要考虑的另一个解决方案是让管理员或自动化流程来创建它们。应对这种情况的最佳方法应该考虑到：
- 组织的规模
- 用户被创建的频率
- 是否涉及到跨域的操作
下面的部分提供了该解决方案的几个变体：
手动创建
让管理员手动为新身份创建帐户只适用于非常小的组织（只有很少的几十个用户），很少需要添加新用户和应用程序。对于非常小的组织，实现帐户配置自动化的工作可能是不合理的。在缺乏自动化的情况下，可以使用书面程序和检查表来确保始终遵循必要的帐户设置步骤。如果密码用作凭据，则帐户设置过程应确保管理员不知道用户的密码。这可以通过向用户发送密码重置链接和/或在初次登录时要求密码重置来完成。如果组织增长或开始需要更多的应用程序，某种形式的自动化将有利于一致性、准确性、安全性， 以及可追踪性。
自动化创建
这种方法通常用于员工身份。当新员工加入公司时，公司可以使用人力资源（HR）系统中的身份信息自动为该员工创建帐户。如果需要持续创建大量帐户，可以使用工作流软件或专门的帐户设置软件来自动创建帐户并为帐户提供标识属性。
跨域的创建
在几种情况下，可能需要跨域进行帐户设置。这可能发生在：
- 在外部SaaS（软件即服务）应用程序中维护员工帐户
- 在企业标识存储库或应用程序中维护合作伙伴帐户
- 在面向业务的应用程序中维护业务客户用户帐户
- 在合作大学系统中维护客座教授或学生帐户
理想情况下，现代身份验证协议会在登录时将用户档案文件属性传递给身份验证令牌中的应用程序，但是如果需要，可能仍然需要跨域提供或同步身份信息
- 应用程序没有设计从身份验证令牌中提取身份信息的。
- 身份资料文件信息太大，无法在身份验证令牌中传输。
- 用户登录不够频繁，无法及时充分更新用户信息。
在需要时，跨域提供帐户和身份信息通常仍使用专有解决方案，如使用创建于2015年的行业标准协议SCIM（跨域身份管理系统），旨在提供一种更标准的方法，将身份信息从一个域发送到另一个域并进行更新。
表4-6显示了管理员创建帐户的一些优点和缺点。
| 优点 | 缺点 |
|---|---|
| 用户无需填写注册表。 | 如果不是自动化的话，会很费时。 |
| 管理员可以分配权限，以便帐户以所需权限启动。 | 需要注意确保只有用户知道所创建帐户的密码。 |
| 可通过工作流或身份设置软件实现自动化。 | 如果存储在本地，则需承担存储登录凭据相关的责任。 |
表4-6 管理员创建
利用现有外部的身份服务
随着信息科技的发展，很多用户的身份已经在一些知名的网站/应用或者权威的机构已经存在，这些平台也对外提供了身份认证的服务。因此，对于应用除了注册、迁移和创建以外，多了一种选择，利用身份提供者服务中已经存在的用户身份。比如在微信、钉钉、微博这样的社交应用上，由雇主运营的企业身份认证服务，或者政府身份认证服务。使用此选项，这允许用户使用他们已经拥有的帐户进行认证，应用程序将对用户进行身份验证的责任委托给身份提供者，并接收回一个安全令牌，其中包含有关用户的已验证会话的信息，以及有关用户的属性（可选）。
利用现有身份提供者服务中的帐户可能意味着减少用户在注册表单中输入的数据。这通常也意味着用户不需要设置另一个密码。如果您不必实现登录表单或帐户恢复机制，因为所有用户都通过身份提供程序服务进行身份验证，那么这可能会减少开发工作。如果您的基础结构中没有存储用户密码，那么还可以在一定程度上降低风险。如果身份提供程序服务不包含应用程序所需的有关用户的所有属性，则您可以随时在以后收集其他数据。 4-7总结了使用外部身份服务的一些优点和缺点。
| 优点 | 缺点 |
|---|---|
| 更好的用户体验，如果它减少了注册所需的数据。 | 您可能需要收集身份提供程序服务无法提供的其他配置文件信息。 |
| 如果经常使用身份提供程序帐户，用户更容易记住密码。 | 您需要评估外部标识服务的服务和可用性级别，以确保它满足您的需求。 |
| 如果所有用户都通过身份提供程序服务进行身份验证，则可能不必实现登录窗体或帐户恢复机制。 | 可能需要为要使用的每个身份提供者服务进行额外的开发或配置工作。 |
| 如果不存储用户密码，风险更小。 | 出现问题时，可能需要与其他组织协作解决问题。 |
表4-7 使用外部身份服务
除了现有的身份提供者服务之外，企业也可以设置自己的新身份提供者服务，以供应用程序使用。如果您选择了该路径，那么可以使用许多云服务（IDaaS）来简化任务，并且可以使用以前的任何设置选项来向新的身份提供者服务填充用户。
4.2外部身份服务的类型
如果您选择利用外部标识服务，那么重要的是要考虑由服务发布的标识的强度以及提供者对特定环境的适用性和可用性。身份的强度是决定对身份的信任程度的一个因素，有几个因素会影响身份的强度：
- 用于确定身份的信息的验证
- 防止他人伪造或使用虚假的身份
- 身份的颁发者对某一特定领域具有权威性
表4-8提供了身份与弱身份特征的比较
| 强身份 | 弱身份 |
|---|---|
| 链接到一个真实的、能够对其行为负责的人。 | 匿名的，不能和真人联系。 |
| 在帐户颁发过程中身份属性可以被验证。 | 能够提供验证的属性很少。 |
| 由特定环境下被公认为权威的实体发布。 | 由缺乏公认权威的实体发布。 |
| 包含防止伪造或未经授权使用的机制。 | 缺乏防止伪造或未经授权使用的机制 |
表4-8 强弱身份对比
身份的强度取决于发行人的可信度、身份数据的验证、发行和分发身份背后的实践，比如：发行人与信任发行人身份信息的任何实体之间的协议，无论是隐含的还是明确的。下一节将提供示例。
自注册的身份
自我注册的身份，例如基本QQ或Gmail电子邮件帐户，曾经，这类身份是弱身份典型例子。用户可以使用尚未使用的任何标识符注册这些帐户， 在注册表格中用户不必提供真实的信息，服务提供商也不会验证用户提供的身份数据，因而也不被认为是身份信息的权威。
但是，随着中国网络实名化的要求，如QQ、微信、网易邮箱、淘宝等应用服务商对注册的用户要求更为严格的身份信息和验证要求，因而这些应用的身份服务可以被重用，用于一些其他的用户使用频率并没有那么高的应用，尤其是消费者的应用程序。这为用户提供了方便，而不需要记住每一个应用的身份访问凭证。
组织的身份
许多组织，如公司或大学，将分别为其成员（如员工或学生）颁发在线身份。这样就可以验证用于在组织内建立在线帐户的身份属性，并将帐户与真实的人联系起来。大多数组织在他们的身份服务中实施一些措施，比如最小密码长度和可能更强的身份验证形式，以防止帐户未经授权的使用。企业内部身份标识服务在发行公司的域内可以唯一标识用户。但是，组织内的用户通常不能通过其所在组织的标识服务登录其他组织及或其签约SaaS服务之外的服务。例如，Alice在A学校拥有学号的标识符，但她不能用她的学号在B学校去进行选课，因为B学校的选课应用没有任何基础来信任A学校的标识服务。组织标识服务主要是用于由组织向组织的成员提供特定的服务。当让，后面我们会介绍到，如何建立组织之间的身份信任服务。
政府颁发的身份
过去，政府发布的身份主要在线下使用，如身份证。但是，随着线上经济以及安全措施的加强，政府也逐步的将在线身份向也一些领域开放。政府颁发的身份包含了政府签发的身份证号码、清晰显示面部的照片、居住地址、甚至包含一些信用的数据。这些身份正在向一些可信的行业开放，如银行的账户，过去只能在线下面对面的开通，可以通过远程的身份验证进行线上的开户。如，旅店行业，即便没有携带身份证的情况下，也可以进行登记。包括一些政府的公共业务，如交通的罚单、税收的申报等等，也都逐渐的转到线上，使用政府颁发的身份进行验证。
行业的身份
移动网络运营商的身份是一个特殊的载体，用户在申请移动电话号码的时候，会经过严格的实名验证。并且签发后它与一张Sim卡绑定，这张卡具有异乎寻常的安全加固措施，极难被复制和伪造。因而，持有这样卡片的人，几乎等同于持有政府颁发的身份。但这里仅仅是几乎，因为一个人可以拥有多张手机卡，仍然存在他把这张卡主观的或被动的交由他人使用的情况。但对于绝大多数线上的业务，没有那么严格要求消费者身份的场景下，拥有该手机卡使用权的用户，等同于注册该卡片人的身份。
4.3身份提供商选择
面向消费者
如果您正在创建一个面向消费者的应用程序，该应用程序不需要收集用户过多的信息，允许用户通过现有的自注册身份（如社交提供商帐户，微信、Facebook，或流行的应用如Github、Google等）进行身份验证，这将为用户在多个站点使用相同的自注册信息进行注册提供便利。
或者可以使用运营商提供的身份进行注册，兼顾了用户注册的便捷性，也确保了身份的真实性。
面向员工
创建面向员工的应用程序，如果依赖社交身份提供者帐户访问公司应用程序可能会有问题，因为用户是在公共的身份供应商处拥有他们的身份。这些提供商的凭据标准可能不满足公司需要，当员工离开公司时，您无法删除他们的帐户以终止他们的访问。
当然，也有另外一种解决的办法，为了让员工登录更方便，可以将社交提供商帐户与本地应用程序的员工帐户建立绑定关联关系，以启用通过社交登录的方式访问应用程序。如果员工离职，则可以删除绑定关系，并禁用本地帐户。因此，对于面向员工的应用程序，最好使用由组织帐户的身份服务。
组织控制的身份标识服务提供了统一的身份控制的中心，在员工成员入职或者离开组织时，可以在通过其实现账号供给和关闭。它还提供了一个单点的认证，在这个点上可以强制执行凭据强度/策略，部署多因素身份验证以及记录相关的事件日志。如今，有些身份云供应商可以以订阅的方式提供标准的身份服务，诸如Okta、XAuth、AzureAD和Amazon Cognito等云服务提供基于云的身份服务。组织可以向员工或成员提供这些服务，并完全控制帐户，包括快速终止或禁用离职人员的帐户。
面向B2B合作伙伴
如果您正在创建一个面向B2B企业的应用程序，您可能需要支持各种不同的身份提供者，因为每个企业可能都有自己的身份提供者，并希望其用户通过其选择的身份提供者登录到您的应用程序。您的客户可能会要求您支持针对云身份提供商的身份验证，如前面提到的Okta，XAuth等等，或者针对他们自己在公司网络上运营的私有身份提供商的身份验证。最好通过标准的身份协议（如OIDC或SAML）来实现。直接对客户的内部托管数据库或目录服务实现身份验证不仅涉及到每个客户和服务器的定制工作，会使您的员工有可能接触到您的客户密码或管理权限，从而增加您的责任。
表 4-9总结了不同场景中最常见的身份提供者类型。
| 场景 | 可选择的身份服务商 |
|---|---|
| B2C：面向消费者 | 社交登录：微信、微博、Github、Gmail等， 运营商身份服务 聚合身份服务商：Okta、XAuth、Firebase、Cognito |
| B2E：面向员工 | 身份服务商：Okta 、XAuth、AzureAD等 |
| B2B：面向合作伙伴 | 身份服务商：Okta、XAuth、AzureAD 或其他支持OIDC、SAML的身份服务 |
表4-9 常见外部身份
4.4选择一个验证身份的属性
在身份供给的阶段，用哪个属性来标识一个用户，即关于如何识别一个用户，总是一个有争议的问题。
电子邮件作为标识
电子邮件地址已被广泛用作识别码。使用电子邮件地址作为标识符的优点是它包含域名，天然的提供了一个跨域的唯一性。这样就不需要用户在每个站点上找到一个尚未使用的名称。然而，这种方式并非没有问题。比如，用户可能需要改变他们的电子邮件地址，但仍然期望保留访问他们的帐户。对于有些企业，可能不向员工提供电子邮件帐户，如果应用程序假定电子邮件地址可用，这可能是一个问题。类似地，有些儿童可能没有电子邮件地址。
用户名作为标识
使用用户自主选择的用户名。这种方式也有优点和缺点。用户名可以使一个人更容易设置多个帐户，并且通常更短，因此更容易在移动设备上键入。用户必须选择一个唯一的用户名，但是，如果他们常用的用户名可能已经在被别人占用，他们必须选择另一个。用户可能很难记住每个站点使用的是哪个用户名，这可能会导致忘记用户名功能的需要。当一家公司收购另一家公司时，通常需要合并用户存储库，这可能需要消除重复的用户名。
手机号码作为标识
手机号码作为全球唯一的标识，能够作为一种强身份标识，被面向消费者的应用广泛应用。使用手机号码，通过手机号码的验证码能够简化用户的注册流程。并且运营商针对手机端，提供了一种无密码登录的方式，大大降低了移动端用户认证的复杂度，提升了用户的体验。 但手机号码作为身份标识可能也面临一些问题，如用户可能会更换手机号码，但仍然期望保留账户。存储手机号码，涉及到用户的敏感信息，需要承担更多的责任。
表 4-10列出了不同标识符的一些共同优点和缺点。
| 方式 | 优点 | 缺点 |
|---|---|---|
| 电子邮件 | 全球唯一标识 比用户名更容易记忆 | 用户可能需要变更邮件，但需要保留账户。 某些用户可能没有邮箱 |
| 用户名 | 没有暴露用户的身份信息 比邮件更短，更容易输入 | 只在某一应用里唯一，如果被占用，其他人无法再注册 无法进行两个系统的合并 用户拥有多个站点的用户名后，不容易记忆 |
| 手机号 | 全球唯一标识 比用户名更容易记忆 强身份标识，可以用于账号恢复 | 用户可能需要变更手机号，但需要保留账户。 认证过程可能带来一定的费用 涉及到用户的隐私，需要谨慎对待 |
表4-10 账户的标识符
对于标识符的建议
前面列出的一些缺点源于将同一属性用于多种目的。可以通过解耦，来避免这些问题，让不同的属性用作不同的目的，包括：
- 用于登录的标识符
- 用于显示账户的名称
- 用于通知和账户恢复
- 用于应用内的行为标记，包括
- 将身份/帐户链接到应用内的操作
- 在日志文件中记录用户活动
列表中的最后两个用于应用内帐户的实现，并且应使用唯一的内部帐户标识符，该标识符不受用户更改其电子邮件、电话号码或法定名称等用户属性变更的影响。此外，以下建议可以避免表4-10中列出的其他一些缺点 :
- 避免暴露可能包含个人数据的标识符
- 在日志文件中使用内部帐户标识符以避免直接暴露日志中的个人数据。
- 在申请记录中使用内部账户标识符。
- 允许用户指定用于屏幕/打印输出的显示名称，以保护隐私。
- 登录、显示和通知的标识符/属性可以根据需要变更。
- 允许为通知目的设置多个属性，如主电子邮件和辅助电子邮件，以防其中一个无法操作。
- 允许长用户名带有特殊字符，并且用户可以更改，这将实现灵活性，包括 如果允许用户使用更容易记住的电子邮件，同时也允许其他用户使用其他值。
验证关键属性
除了为不同的目的，使用不同的用户属性外。在影响安全和隐私的活动中，也需要对一些关键的属性进行验证，这包括验证电子邮件、手机号码等等。验证后的属性可以用于
- 授权决定
- 账户恢复
- 向用户提供敏感信息
例如，如果用户的账户资料包括电子邮件地址，并且电子邮件地址属性用于授权决策，您应该实现电子邮件地址验证。同样，用于帐户恢复或敏感信息传递中通知的属性，需要严格的验证，包括电子邮件地址、电话号码。如果您从其他地方导入标识，则应确保用于以上用途的电子邮件地址或其他关键属性之前已经过验证。
未经验证的属性可能会产生与安全和隐私相关的问题。
如果用户可以使用虚构的、未经验证的电子邮件地址注册，并且此属性用于授权，则一些授权会授予给这些恶意虚构的用户，让其拥有的本不应该让他们访问的一些资源的访问权限。另外，严格验证电子邮件地址还可以防止意外输入不正确的地址，以造成错误，让他人通过帐户恢复机制接管帐户，或导致将敏感信息传递给错误的收件人。
4.5本章重点回顾
本章介绍了几种可用于为应用程序用户建立帐户的方法，包括自注册、渐进式登记、从其他地方转移用户、管理员创建和利用身份提供商服务。在选择账户的标识符时，您需要根据应用程序的敏感度和目标受众来考虑每个选项提供的标识的强度和适用性。一旦您知道如何创建用户，就可以开始实现身份验证和访问控制。现代应用程序通常是从API开始设计的，因此我们将在下一章从OAuth2.0开始，OAuth2.0是为保护API而设计。