diff --git a/README.md b/README.md index d7004b2..b20a864 100644 --- a/README.md +++ b/README.md @@ -1 +1,10 @@ -# - 一本关于如何做好身份管理的书 a new book +--- +description: An awesome identity book talk about how to build a morden identity. +--- + +# 现代身份建设指南 + +## 一本如何做好现代身份管理的书 + +## + diff --git a/SUMMARY.md b/SUMMARY.md new file mode 100644 index 0000000..aa55dea --- /dev/null +++ b/SUMMARY.md @@ -0,0 +1,31 @@ +# Table of contents + +* [现代身份建设指南](README.md) + +## 现代身份建设指南 + +* [引言](xian-dai-shen-fen-jian-she-zhi-nan/introduction.md) + +## 关于身份 + +--- + +* [第一章 现代身份的挑战](chapterone.md) +* [第二章 身份的生命周期](chaptertwo.md) +* [第三章 身份演进历史](chapterthree.md) +* [第四章 身份的供给/生成](chapterfour.md) +* [第五章 API安全的成熟度模型](chapterfive.md) + +## 协议 + +* [第六章 深入学习OAuth2.0](xie-yi/chaptersix.md) +* [第七章 OpenID Connect](xie-yi/chapterseven.md) +* [第八章 深入学习SAML2.0](xie-yi/chaptereight.md) + +## 设计 + +* [第九章 授权与访问策略执行](she-ji/chapternine.md) +* [第十章 Sessions 会话](she-ji/chapterten.md) +* [第十一章 单点登录SSO](she-ji/chaptereleven.md) +* [第十二章 强身份认证](she-ji/chaptertwelve.md) + diff --git a/docs/modernidentity/ChapterFive.md b/chapterfive.md similarity index 90% rename from docs/modernidentity/ChapterFive.md rename to chapterfive.md index bbed505..6136277 100644 --- a/docs/modernidentity/ChapterFive.md +++ b/chapterfive.md @@ -8,18 +8,16 @@ 事实上，API的安全的演进也并非一触而就，也经历了一系列的演进。参考Richardson RMM（ API成熟度模型），该模型概述了Web API服务开发成熟度的四个层级。相对应的，从安全角度，构建了API的安全成熟度模型。在这个模型中，随着等级升高，安全性和信任度就越高。 -- Level 0: API 密钥和基础认证 ，API Keys and Basic Authentication - -- Level 1: 基于令牌的认证，Token-Based Authentication -- Level 2: 基于令牌的授权，Token-Based Authorization - -- Level 3: 基于声明的集中式信任，Centralized Trust Using Claims +* Level 0: API 密钥和基础认证 ，API Keys and Basic Authentication +* Level 1: 基于令牌的认证，Token-Based Authentication +* Level 2: 基于令牌的授权，Token-Based Authorization +* Level 3: 基于声明的集中式信任，Centralized Trust Using Claims ![5-1 API Security Model.png](https://i.loli.net/2021/07/16/mhWVXogISRsQ9ju.png) ### Level 0 API密钥和基础认证 -级别0的API使用基本身份验证或API密钥来验证API调用。这些值插入在API请求的URL的标头(Header)或正文(Body)中。大多数早期的API都采用这种方式。 +级别0的API使用基本身份验证或API密钥来验证API调用。这些值插入在API请求的URL的标头\(Header\)或正文\(Body\)中。大多数早期的API都采用这种方式。 例如，一个电子商务商店的应用，它根据用户购买情况对付款API进行API调用。它将身份验证以标头中的API密钥或基本身份验证的形式发送给应用程序，并将其传递给API。将用户的ID放在正文或URL中。在下面的示例中，有两类API：账单类和商品类。由于采用HTTP基本身份验证或API密钥方式，API仅对“商店应用”进行身份验证，因此“商店应用”必须向API传递用户数据。 @@ -47,7 +45,7 @@ 为了解决以上级别1的缺陷，在令牌的设计上，级别2在基于令牌认证的体系结构上，引入了授权机制。即，通过描述请求方的特权，询问请求方将被允许做什么？这一思想被应用到Oauth2.0中，作为一种广泛采用的授权标准。 -OAuth最大的亮点是在token中包含了作用范围（标准中定义为Scope），范围Scope可以在授权令牌中包含“指定的权限”，即作用范围可以指定用户权限。 这一优点在后续的协议中又得以进一步的规范，如后续的OpenID Connect定义了一组标准的[作用范围]，即可以用来生成标准的身份参数。当然，开发者除了标准范围以外，也可以创建[自定义范围]用于自己开发的API。范围可以根据开发者需求包含更多和授权相关的数据，以用于后续的API的授权，这比“ if”语句的编码方式要更为友好和优雅。 +OAuth最大的亮点是在token中包含了作用范围（标准中定义为Scope），范围Scope可以在授权令牌中包含“指定的权限”，即作用范围可以指定用户权限。 这一优点在后续的协议中又得以进一步的规范，如后续的OpenID Connect定义了一组标准的\[作用范围\]，即可以用来生成标准的身份参数。当然，开发者除了标准范围以外，也可以创建\[自定义范围\]用于自己开发的API。范围可以根据开发者需求包含更多和授权相关的数据，以用于后续的API的授权，这比“ if”语句的编码方式要更为友好和优雅。 这时，让我们再次回顾我们的电子商店的案例。现在，我们引入了通过范围进行授权，因此可以更加容易的实现公共网络的商店和后台可以具有不同的特权。比如，只有管理后台应用才能获取添加商品（AddProduct）的权限。这就有效的区分了不同应用的权限。 @@ -59,8 +57,6 @@ OAuth最大的亮点是在token中包含了作用范围（标准中定义为Scop 级别2的问题：级别2中的一个问题是系统面临着反编译的威胁。如果将身份的信息直接放在在API参数中，通过对于API的访问进行逆向，其中的逻辑错误很容易被发现和利用。 另外，级别2中引入了更高的系统复杂度，因为某些API请求参数可能会依赖其他API响应或其他条件。如果，一个API调用另一个API时失败了，或者，如果数据请求参数中包含了错误，怎么办？我们不能假设数据从一个API传递到下一个API总是正确的。这些现实问题可能会导致一系列的级联信任问题，这种“意大利面条式的信任”，有可能让系统变成一团糟。 - - ## Level 3: 基于声明的集中式信任，Centralized Trust Using Claims 通过对以上各级的问题的总结，最终API的安全计划到第3级，可以认为是目前最完善的API安全思想和实践。这种实践引入了使用Claims和签名的JSON Web令牌（JWT）进行集中式信任。 @@ -83,16 +79,15 @@ OAuth最大的亮点是在token中包含了作用范围（标准中定义为Scop 这种方法通过信任令牌的发行者，而不是信任参数本身的方式，有效的解决了各级信任问题。从而达成集中式的授权机制。 - - ## 本章重点回顾 信任是主观的东西。在设计基于API的安全系统时，我们应该信任密钥、令牌，密码，机器或用户本身吗？答案要比大多数的API设计人员认为的要复杂，但这对于保护您的平台整体至关重要。 - 本质上，API安全的顶峰是信任声明，而不是属性。如果没有考虑更高级的安全性，如果GitHub存储库中存在重要的密钥，API很容易受到攻击。因此，API提供者必须做出更明智的安全决策，以保护整个平台的完整性。 +本质上，API安全的顶峰是信任声明，而不是属性。如果没有考虑更高级的安全性，如果GitHub存储库中存在重要的密钥，API很容易受到攻击。因此，API提供者必须做出更明智的安全决策，以保护整个平台的完整性。 正如API安全成熟度模型逐步演进所显示的那样，高度成熟的API只信任很少的源，这些演化的API被信任的令牌的发行者逐渐成为独立的服务。这不能保证100%的真实性，但最接近于验证请求方的身份。通过标准逐渐固化信任标准过程，可以消除系统开发者在身份授权的自定义代码上浪费的精力。 事实上，在网络安全领域，很少鼓励你发明自己的授权规则。为了使集中信任发挥作用，授权系统需要使用稳定的协议。就像街道交通规则一样，身份系统也遵循通用协议。需要它们自己的共享开放标准，这些协议就是OAuth和OpenID Connect。利用这些标准，应用程序可以在JWTs中共享安全的断言数据以进行验证。 下一章将详细的介绍OAuth。 + diff --git a/docs/modernidentity/ChapterFour.md b/chapterfour.md similarity index 77% rename from docs/modernidentity/ChapterFour.md rename to chapterfour.md index 60e90d3..7286bd8 100644 --- a/docs/modernidentity/ChapterFour.md +++ b/chapterfour.md @@ -6,14 +6,11 @@ 对于应用程序开发人员来说，身份供给阶段包括获取用户并为他们创建帐户和身份配置文件。通常，最简单的理解是让用户注册应用程序的帐户，但这不是唯一的选择。正对不同的场景，身份供给的常用方式包括： -- 用户通过注册填写信息登记表单来创建新身份。 - -- 特定用户通过注册邀请来填写账户注册表单。 - -- 从以前存在的用户存储库转化而来。 - -- 管理员或自动化进程创建用户身份信息。 -- 利用具有现有用户标识存储库的身份服务。 +* 用户通过注册填写信息登记表单来创建新身份。 +* 特定用户通过注册邀请来填写账户注册表单。 +* 从以前存在的用户存储库转化而来。 +* 管理员或自动化进程创建用户身份信息。 +* 利用具有现有用户标识存储库的身份服务。 这些方法不是相互排斥的；在某些情况下，多种方法的结合可能最有效。我们将更详细地描述每种方法，以及每种方法的优缺点。 @@ -25,13 +22,13 @@ 表 4-1总结了使用登记表的一些优点和缺点。 -| 优点 | 缺点 | -| :--------------------------------- | :----------------------------------------------------------- | +| 优点 | 缺点 | +| :--- | :--- | | 能够收集其他地方不存在的用户属性。 | 一些潜在的新的用户不愿意填写注册信息，可能会影响新用户的注册。 | -| 可以控制用户注册体验。 | 承担存储登录凭据相关的责任。 | -| 通过自助服务实现可扩展性。 | | +| 可以控制用户注册体验。 | 承担存储登录凭据相关的责任。 | +| 通过自助服务实现可扩展性。 | | -
表4-1 用户自注册
+ 表4-1 用户自注册 #### 渐进式注册 @@ -57,14 +54,14 @@ 邀请注册方法的一些优点和缺点如表所示 4-2. -| 优点 | 缺点 | -| ---------------------------------- | ------------------------------------------------------------ | +| 优点 | 缺点 | +| :--- | :--- | | 能够收集其他地方不存在的用户属性。 | 一些潜在的新的用户不愿意填写注册信息，可能会影响新用户的注册 | -| 控制用户注册体验。 | 承担存储登录凭据相关的责任。 | -| 通过自助服务实现可扩展性。 | 需要额外设计发出邀请的工作。 | -| 防止黑客和机器人注册。 | 对于邀请链接和控制其访问的额外开发工作。 | +| 控制用户注册体验。 | 承担存储登录凭据相关的责任。 | +| 通过自助服务实现可扩展性。 | 需要额外设计发出邀请的工作。 | +| 防止黑客和机器人注册。 | 对于邀请链接和控制其访问的额外开发工作。 | -
表4-2 邀请注册
+ 表4-2 邀请注册 ### 身份迁移 @@ -74,17 +71,17 @@ 散列密码有不同的算法，传递给散列算法的输入也不同，例如salt和迭代计数。因此，在一个系统中散列的密码不一定能被另一个系统导入和使用。如果两个不同的系统使用不同的散列算法或同一算法的不同输入，则不可能将散列密码从一个系统移动到另一个系统并使其可供新系统使用。在这种情况下，有几种解决办法考虑迁移身份 一个新的系统。 -#### 支持遗留系统哈希算法 +#### 支持遗留系统哈希算法 一种解决方案是更新新系统以支持遗留系统使用的哈希算法。这需要在新系统中实现遗留系统的哈希算法，以及确定每个帐户使用哪个哈希算法的方法。这将允许将所有身份数据和散列密码从旧系统移动到新系统，而无需用户重置密码。表 4-3总结了支持传统哈希算法的一些优点和缺点。 -| 优点 | 缺点 | -| ------------------------ | ------------------------------ | -| 无需重新设置密码。 | 实施遗留哈希算法。 | -| 以可用状态转移所有帐户。 | 承担存储登录凭据相关的责任。 | -| | 继承与遗留哈希算法相关的缺点。 | +| 优点 | 缺点 | +| :--- | :--- | +| 无需重新设置密码。 | 实施遗留哈希算法。 | +| 以可用状态转移所有帐户。 | 承担存储登录凭据相关的责任。 | +| | 继承与遗留哈希算法相关的缺点。 | -
表4-3 全部迁移
+ 表4-3 全部迁移 #### 批量密码重置 @@ -92,43 +89,39 @@ 表 4-4总结了批量转移用户的一些优点和缺点。 -| 优点 | 缺点 | -| -------------------------------------------------- | ------------------------------------------------------------ | -| 一次传输所有用户。 | 需要转移所有帐户，即使是非活动帐户，除非在转移过程中过滤掉它们。 | -| 支持立即关闭旧用户存储库。 | 要求所有用户通过帐户恢复设置新密码，除非新系统可以支持旧的哈希密码。 | +| 优点 | 缺点 | +| :--- | :--- | +| 一次传输所有用户。 | 需要转移所有帐户，即使是非活动帐户，除非在转移过程中过滤掉它们。 | +| 支持立即关闭旧用户存储库。 | 要求所有用户通过帐户恢复设置新密码，除非新系统可以支持旧的哈希密码。 | | 在登录时无需去就系统验证，降低验证凭据带来的延迟。 | 需要缜密的规划，否则如果迁移出现问题且没有备份计划，可能会导致大范围的中断。 | -| 传输身份的代码可以独立于应用程序代码。 | 承担与存储登录凭据相关的责任。 | +| 传输身份的代码可以独立于应用程序代码。 | 承担与存储登录凭据相关的责任。 | -
表4-4 批量迁移但不包含密码
+ 表4-4 批量迁移但不包含密码 #### 逐步迁移用户 -批量密码重置之外，可以改进的是使用热更新的机制，在用户登录时逐渐迁移身份。这需要一种登录机制，该机制提示用户输入凭据，根据旧存储库对其进行验证，如果验证通过，则从旧存储库检索身份信息，并将其和输入的凭据存储在新存储库中。在对遗留系统进行验证之后，用户输入的密码由新系统使用其哈希算法进行哈希运算，并存储在用户的新帐户中。这种方式将仅迁移登录并要求新系统验证的用户（事实上，新系统在迁移之前仍然访问旧系统并验证输入的凭证和检索用户身份信息）。这对用户来说更方便，因为不需要重置密码，但这意味着在迁移标识之前，遗留系统必须保持可操作性。此解决方案不会转移非活动帐户 (未登录的用户）。 +批量密码重置之外，可以改进的是使用热更新的机制，在用户登录时逐渐迁移身份。这需要一种登录机制，该机制提示用户输入凭据，根据旧存储库对其进行验证，如果验证通过，则从旧存储库检索身份信息，并将其和输入的凭据存储在新存储库中。在对遗留系统进行验证之后，用户输入的密码由新系统使用其哈希算法进行哈希运算，并存储在用户的新帐户中。这种方式将仅迁移登录并要求新系统验证的用户（事实上，新系统在迁移之前仍然访问旧系统并验证输入的凭证和检索用户身份信息）。这对用户来说更方便，因为不需要重置密码，但这意味着在迁移标识之前，遗留系统必须保持可操作性。此解决方案不会转移非活动帐户 \(未登录的用户）。 使用渐进迁移方法，一部分用户可能在迁移期间并没有登录，因此无法迁移其身份信息。您可以设置迁移的截止日期，并决定如何处理在该日期之前尚未迁移的任何标识。一种可能是宣布未迁移的帐户处于非活动状态，并放弃它们。一种常见的方法是使用批量移动非活动帐户（不包含散列的密码），如上一小节描述，这样就可以解除旧系统的运行。如果不迁移所有剩余的标识，则应考虑保留未迁移标识的帐户标识符，以防止将来新帐户使用它们。 对于身份尚未迁移的用户，可以使用新系统输入电子邮件并获得密码重置令牌或链接。用户将确认收到电子邮件，并提示输入新密码。新系统将为新系统中的用户创建一个帐户，其中包含从旧系统中检索到的具有匹配电子邮件地址的帐户的信息。活动标识的逐步迁移，再加上剩余身份的大量迁移和凭证重置，为活跃用户提供了一种良好的用户体验，同时不放弃不经常的用户。表 4-5总结了逐步迁移的一些优点和缺点。 +| 优点 | 缺点 | +| :--- | :--- | +| 不活跃的帐户可以剔除。 | 要求可以从新应用程序的身份验证机制访问旧标识存储。在传输足够的标识之前，旧标识存储必须保持可访问性。 | +| 无需重置密码 \(对于在迁移期间登录的用户）。 | 在逐步迁移的过程中，必须保持迁移机制。 | +| 通过逐步迁移身份分散停机风险（无大面积故障风险）。 | 因为身份数据需要从遗留系统读取，用户在迁移开始后的首次登录可能会有一些延迟。 | +| 可以支持在渐进迁移期间继续使用以前的注册机制或使用遗留标识存储库的应用程序。 | 需要额外的开发实现 | +| | 承担存储登录凭据相关的责任。 | - -| 优点 | 缺点 | -| ------------------------------------------------------------ | ------------------------------------------------------------ | -| 不活跃的帐户可以剔除。 | 要求可以从新应用程序的身份验证机制访问旧标识存储。在传输足够的标识之前，旧标识存储必须保持可访问性。 | -| 无需重置密码 (对于在迁移期间登录的用户）。 | 在逐步迁移的过程中，必须保持迁移机制。 | -| 通过逐步迁移身份分散停机风险（无大面积故障风险）。 | 因为身份数据需要从遗留系统读取，用户在迁移开始后的首次登录可能会有一些延迟。 | -| 可以支持在渐进迁移期间继续使用以前的注册机制或使用遗留标识存储库的应用程序。 | 需要额外的开发实现 | -| | 承担存储登录凭据相关的责任。 | - -
表4-5 逐步迁移
+ 表4-5 逐步迁移 ### 管理员创建 创建帐户和身份需要考虑的另一个解决方案是让管理员或自动化流程来创建它们。应对这种情况的最佳方法应该考虑到： * 组织的规模 - * 用户被创建的频率 - * 是否涉及到跨域的操作 下面的部分提供了该解决方案的几个变体： @@ -145,30 +138,28 @@ 在几种情况下，可能需要跨域进行帐户设置。这可能发生在： -- 在外部SaaS（软件即服务）应用程序中维护员工帐户 -- 在企业标识存储库或应用程序中维护合作伙伴帐户 - -- 在面向业务的应用程序中维护业务客户用户帐户 -- 在合作大学系统中维护客座教授或学生帐户 +* 在外部SaaS（软件即服务）应用程序中维护员工帐户 +* 在企业标识存储库或应用程序中维护合作伙伴帐户 +* 在面向业务的应用程序中维护业务客户用户帐户 +* 在合作大学系统中维护客座教授或学生帐户 理想情况下，现代身份验证协议会在登录时将用户档案文件属性传递给身份验证令牌中的应用程序，但是如果需要，可能仍然需要跨域提供或同步身份信息 -- 应用程序没有设计从身份验证令牌中提取身份信息的。 -- 身份资料文件信息太大，无法在身份验证令牌中传输。 - -- 用户登录不够频繁，无法及时充分更新用户信息。 +* 应用程序没有设计从身份验证令牌中提取身份信息的。 +* 身份资料文件信息太大，无法在身份验证令牌中传输。 +* 用户登录不够频繁，无法及时充分更新用户信息。 在需要时，跨域提供帐户和身份信息通常仍使用专有解决方案，如使用创建于2015年的行业标准协议SCIM（跨域身份管理系统），旨在提供一种更标准的方法，将身份信息从一个域发送到另一个域并进行更新。 表4-6显示了管理员创建帐户的一些优点和缺点。 -| 优点 | 缺点 | -| -------------------------------------------- | ------------------------------------------------ | -| 用户无需填写注册表。 | 如果不是自动化的话，会很费时。 | -| 管理员可以分配权限，以便帐户以所需权限启动。 | 需要注意确保只有用户知道所创建帐户的密码。 | -| 可通过工作流或身份设置软件实现自动化。 | 如果存储在本地，则需承担存储登录凭据相关的责任。 | +| 优点 | 缺点 | +| :--- | :--- | +| 用户无需填写注册表。 | 如果不是自动化的话，会很费时。 | +| 管理员可以分配权限，以便帐户以所需权限启动。 | 需要注意确保只有用户知道所创建帐户的密码。 | +| 可通过工作流或身份设置软件实现自动化。 | 如果存储在本地，则需承担存储登录凭据相关的责任。 | -
表4-6 管理员创建
+ 表4-6 管理员创建 ### 利用现有外部的身份服务 @@ -176,38 +167,35 @@ 利用现有身份提供者服务中的帐户可能意味着减少用户在注册表单中输入的数据。这通常也意味着用户不需要设置另一个密码。如果您不必实现登录表单或帐户恢复机制，因为所有用户都通过身份提供程序服务进行身份验证，那么这可能会减少开发工作。如果您的基础结构中没有存储用户密码，那么还可以在一定程度上降低风险。如果身份提供程序服务不包含应用程序所需的有关用户的所有属性，则您可以随时在以后收集其他数据。 4-7总结了使用外部身份服务的一些优点和缺点。 -| 优点 | 缺点 | -| ------------------------------------------------------------ | ------------------------------------------------------------ | -| 更好的用户体验，如果它减少了注册所需的数据。 | 您可能需要收集身份提供程序服务无法提供的其他配置文件信息。 | -| 如果经常使用身份提供程序帐户，用户更容易记住密码。 | 您需要评估外部标识服务的服务和可用性级别，以确保它满足您的需求。 | +| 优点 | 缺点 | +| :--- | :--- | +| 更好的用户体验，如果它减少了注册所需的数据。 | 您可能需要收集身份提供程序服务无法提供的其他配置文件信息。 | +| 如果经常使用身份提供程序帐户，用户更容易记住密码。 | 您需要评估外部标识服务的服务和可用性级别，以确保它满足您的需求。 | | 如果所有用户都通过身份提供程序服务进行身份验证，则可能不必实现登录窗体或帐户恢复机制。 | 可能需要为要使用的每个身份提供者服务进行额外的开发或配置工作。 | -| 如果不存储用户密码，风险更小。 | 出现问题时，可能需要与其他组织协作解决问题。 | +| 如果不存储用户密码，风险更小。 | 出现问题时，可能需要与其他组织协作解决问题。 | -
表4-7 使用外部身份服务
+ 表4-7 使用外部身份服务 除了现有的身份提供者服务之外，企业也可以设置自己的新身份提供者服务，以供应用程序使用。如果您选择了该路径，那么可以使用许多云服务（IDaaS）来简化任务，并且可以使用以前的任何设置选项来向新的身份提供者服务填充用户。 - - ## 4.2外部身份服务的类型 如果您选择利用外部标识服务，那么重要的是要考虑由服务发布的标识的强度以及提供者对特定环境的适用性和可用性。身份的强度是决定对身份的信任程度的一个因素，有几个因素会影响身份的强度： -- 用于确定身份的信息的验证 -- 防止他人伪造或使用虚假的身份 - -- 身份的颁发者对某一特定领域具有权威性 +* 用于确定身份的信息的验证 +* 防止他人伪造或使用虚假的身份 +* 身份的颁发者对某一特定领域具有权威性 表4-8提供了身份与弱身份特征的比较 -| 强身份 | 弱身份 | -| ---------------------------------------- | -------------------------------- | -| 链接到一个真实的、能够对其行为负责的人。 | 匿名的，不能和真人联系。 | -| 在帐户颁发过程中身份属性可以被验证。 | 能够提供验证的属性很少。 | -| 由特定环境下被公认为权威的实体发布。 | 由缺乏公认权威的实体发布。 | -| 包含防止伪造或未经授权使用的机制。 | 缺乏防止伪造或未经授权使用的机制 | +| 强身份 | 弱身份 | +| :--- | :--- | +| 链接到一个真实的、能够对其行为负责的人。 | 匿名的，不能和真人联系。 | +| 在帐户颁发过程中身份属性可以被验证。 | 能够提供验证的属性很少。 | +| 由特定环境下被公认为权威的实体发布。 | 由缺乏公认权威的实体发布。 | +| 包含防止伪造或未经授权使用的机制。 | 缺乏防止伪造或未经授权使用的机制 | -
表4-8 强弱身份对比
+ 表4-8 强弱身份对比 身份的强度取决于发行人的可信度、身份数据的验证、发行和分发身份背后的实践，比如：发行人与信任发行人身份信息的任何实体之间的协议，无论是隐含的还是明确的。下一节将提供示例。 @@ -229,8 +217,6 @@ 移动网络运营商的身份是一个特殊的载体，用户在申请移动电话号码的时候，会经过严格的实名验证。并且签发后它与一张Sim卡绑定，这张卡具有异乎寻常的安全加固措施，极难被复制和伪造。因而，持有这样卡片的人，几乎等同于持有政府颁发的身份。但这里仅仅是几乎，因为一个人可以拥有多张手机卡，仍然存在他把这张卡主观的或被动的交由他人使用的情况。但对于绝大多数线上的业务，没有那么严格要求消费者身份的场景下，拥有该手机卡使用权的用户，等同于注册该卡片人的身份。 - - ## 4.3身份提供商选择 > 面向消费者 @@ -253,13 +239,13 @@ 表 4-9总结了不同场景中最常见的身份提供者类型。 -| 场景 | 可选择的身份服务商 | -| ----------------- | ------------------------------------------------------------ | -| B2C：面向消费者 | 社交登录：微信、微博、Github、Gmail等，
运营商身份服务
聚合身份服务商：Okta、OneAuth、Firebase、Cognito | -| B2E：面向员工 | 身份服务商：Okta 、OneAuth、AzureAD等 | -| B2B：面向合作伙伴 | 身份服务商：Okta、OneAuth、AzureAD
或其他支持OIDC、SAML的身份服务 | +| 场景 | 可选择的身份服务商 | +| :--- | :--- | +| B2C：面向消费者 | 社交登录：微信、微博、Github、Gmail等， 运营商身份服务 聚合身份服务商：Okta、OneAuth、Firebase、Cognito | +| B2E：面向员工 | 身份服务商：Okta 、OneAuth、AzureAD等 | +| B2B：面向合作伙伴 | 身份服务商：Okta、OneAuth、AzureAD 或其他支持OIDC、SAML的身份服务 | -
表4-9 常见外部身份
+ 表4-9 常见外部身份 ## 4.4选择一个验证身份的属性 @@ -275,17 +261,17 @@ > 手机号码作为标识 -手机号码作为全球唯一的标识，能够作为一种强身份标识，被面向消费者的应用广泛应用。使用手机号码，通过手机号码的验证码能够简化用户的注册流程。并且运营商针对手机端，提供了一种无密码登录的方式，大大降低了移动端用户认证的复杂度，提升了用户的体验。 但手机号码作为身份标识可能也面临一些问题，如用户可能会更换手机号码，但仍然期望保留账户。存储手机号码，涉及到用户的敏感信息，需要承担更多的责任。 +手机号码作为全球唯一的标识，能够作为一种强身份标识，被面向消费者的应用广泛应用。使用手机号码，通过手机号码的验证码能够简化用户的注册流程。并且运营商针对手机端，提供了一种无密码登录的方式，大大降低了移动端用户认证的复杂度，提升了用户的体验。 但手机号码作为身份标识可能也面临一些问题，如用户可能会更换手机号码，但仍然期望保留账户。存储手机号码，涉及到用户的敏感信息，需要承担更多的责任。 表 4-10列出了不同标识符的一些共同优点和缺点。 -| 方式 | 优点 | 缺点 | -| -------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -| 电子邮件 | 全球唯一标识
比用户名更容易记忆 | 用户可能需要变更邮件，但需要保留账户。
某些用户可能没有邮箱 | -| 用户名 | 没有暴露用户的身份信息
比邮件更短，更容易输入 | 只在某一应用里唯一，如果被占用，其他人无法再注册
无法进行两个系统的合并
用户拥有多个站点的用户名后，不容易记忆 | -| 手机号 | 全球唯一标识
比用户名更容易记忆
强身份标识，可以用于账号恢复 | 用户可能需要变更手机号，但需要保留账户。
认证过程可能带来一定的费用
涉及到用户的隐私，需要谨慎对待 | +| 方式 | 优点 | 缺点 | +| :--- | :--- | :--- | +| 电子邮件 | 全球唯一标识 比用户名更容易记忆 | 用户可能需要变更邮件，但需要保留账户。 某些用户可能没有邮箱 | +| 用户名 | 没有暴露用户的身份信息 比邮件更短，更容易输入 | 只在某一应用里唯一，如果被占用，其他人无法再注册 无法进行两个系统的合并 用户拥有多个站点的用户名后，不容易记忆 | +| 手机号 | 全球唯一标识 比用户名更容易记忆 强身份标识，可以用于账号恢复 | 用户可能需要变更手机号，但需要保留账户。 认证过程可能带来一定的费用 涉及到用户的隐私，需要谨慎对待 | -
表4-10 账户的标识符
+ 表4-10 账户的标识符 ### 对于标识符的建议 @@ -296,24 +282,18 @@ * 用于通知和账户恢复 * 用于应用内的行为标记，包括 * 将身份/帐户链接到应用内的操作 - * 在日志文件中记录用户活动 + * 在日志文件中记录用户活动 列表中的最后两个用于应用内帐户的实现，并且应使用唯一的内部帐户标识符，该标识符不受用户更改其电子邮件、电话号码或法定名称等用户属性变更的影响。此外，以下建议可以避免表4-10中列出的其他一些缺点 : * 避免暴露可能包含个人数据的标识符 - * 在日志文件中使用内部帐户标识符以避免直接暴露日志中的个人数据。 * 在申请记录中使用内部账户标识符。 * 允许用户指定用于屏幕/打印输出的显示名称，以保护隐私。 - * 登录、显示和通知的标识符/属性可以根据需要变更。 - * 允许为通知目的设置多个属性，如主电子邮件和辅助电子邮件，以防其中一个无法操作。 - * 允许长用户名带有特殊字符，并且用户可以更改，这将实现灵活性，包括 如果允许用户使用更容易记住的电子邮件，同时也允许其他用户使用其他值。 - - ### 验证关键属性 除了为不同的目的，使用不同的用户属性外。在影响安全和隐私的活动中，也需要对一些关键的属性进行验证，这包括验证电子邮件、手机号码等等。验证后的属性可以用于 @@ -328,8 +308,7 @@ 如果用户可以使用虚构的、未经验证的电子邮件地址注册，并且此属性用于授权，则一些授权会授予给这些恶意虚构的用户，让其拥有的本不应该让他们访问的一些资源的访问权限。另外，严格验证电子邮件地址还可以防止意外输入不正确的地址，以造成错误，让他人通过帐户恢复机制接管帐户，或导致将敏感信息传递给错误的收件人。 - - ## 4.5本章重点回顾 本章介绍了几种可用于为应用程序用户建立帐户的方法，包括自注册、渐进式登记、从其他地方转移用户、管理员创建和利用身份提供商服务。在选择账户的标识符时，您需要根据应用程序的敏感度和目标受众来考虑每个选项提供的标识的强度和适用性。一旦您知道如何创建用户，就可以开始实现身份验证和访问控制。现代应用程序通常是从API开始设计的，因此我们将在下一章从OAuth2.0开始，OAuth2.0是为保护API而设计。 + diff --git a/docs/modernidentity/ChapterOne.md b/chapterone.md similarity index 94% rename from docs/modernidentity/ChapterOne.md rename to chapterone.md index 4459fce..b6e67c0 100644 --- a/docs/modernidentity/ChapterOne.md +++ b/chapterone.md @@ -4,8 +4,6 @@ 想象一个场景，你正在开启一个新的软件/在线应用项目，然后你花了大量的时间研究需求、推演方案，设计算法和功能。当你完成了这一系列工作，已经准备好把你关于项目的所有想法付诸实践时。突然你意识这个软件/应用程序需要有身份管理的功能，这时必不可少的你就需要开始考虑用户系统的设计。于是，您开始研究如何创建帐户。刚开始，你可能认为这就是个用户名和密码校验的工作，但是你慢慢的发现，为了更好的引入用户，可能需要社交登录；为了验证用户的安全性需要提供多因素身份验证；为了更好的营销需要引入更多的用户信息，你可能采用的微服务的架构，可能需要服务之间的认证；不同用户拥有不同的权限这时需要基于身份的授权；为了更好的用户体验，需要以上所有这些用户的设计能够跨多个设备使用，等等。这时你才会发现自己在和一个多头的妖怪在战斗，当你解决一个头以后，不断又有新的头冒出来，让你疲于和它战斗，而让你的项目和想法迟滞。如果没有一个很好的计划来处理身份管理，那么解决一个身份管理挑战可能会导致更多的挑战。 - - ## 身份挑战 虽然身份管理在理论上是一个简单的概念，但要使其在实践中如何让身份成为一个支撑而不是一个负担，需要多种因素共同作用。提供良好的用户体验是基础的要求，还需要平衡来自业务需求和安全性的无数期望。因此，身份需要仔细的规划、设计和开发来实现对正在进行的项目提供的良好支撑。不幸的是，身份管理没有一个一刀切的方案，我们没有办法能够构建的一个完美的解决方案适合每一个场景和用例。 @@ -34,8 +32,6 @@ 构建应用程序时的另一个主要关注点是管理敏感身份数据处理和隐私保护的法规。欧盟的GDPR（General Data Privacy Regulation）、中国的数据安全法等法规以及其他地方正在颁布的类似法规的出台，对于收集或处理用户数据的应用程序要求越来越严格，必须符合隐私要求，因为如果违反这些要求，可能会招致严厉的处罚。对于应用程序设计身份管理需要考虑的环节也越来越多。 - - ## 目标 我们写这本书的目的是介绍如何做好身份管理，这些主要根据我们构建和部署应用程序的经验，以及结合目前主流的市场上的解决方案而来。本书重点是软件应用程序的身份管理方面，如创建帐户、身份验证、API授权、单点登录、帐户管理和注销用户。 @@ -58,58 +54,44 @@ 在此之后的章节将介绍用户第一次登录后发生的事情，包括有关会话、单点登录、增强的身份验证形式、帐户管理、注销和取消设置等。如果您的应用程序第一次不能完美地工作，我们包含了一章关于故障排除的指导。我们还分享了可能出现的问题场景的信息，以及我们遇到的一些不寻常的用例。最后，我们简要介绍了法规遵从性以及导致一些非常不幸的违规行为的一些错误。 - - > 术语 我们讨论的协议都使用了不同的术语。不同的协议对于术语有不同的定义，这使得很难对某些组件使用一致的术语。最终我们采用的方式是，在特定协议的章节中，我们使用该协议使用的特定术语。而在其他章节中，我们将使用更通用的术语。例如，在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 | 服务提供方-应用程序 | +| 协议 | 术语 | 中文 | +| :--- | :--- | :--- | +| 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协议的示例应用程序。通过示例，介绍身份协议是如何使用的。 +为了更好的说明，我们将提供了一个使用OIDC和OAuth2.0协议的示例应用程序。通过示例，介绍身份协议是如何使用的。 在开始阅读本文或者开始设计身份系统之前，我们建议考虑以下问题，带着这些问题或许对于后续章节要解决的问题有更深入的理解： **问题设计** * 身份的需要包含哪些类型用户：员工、客户、合作伙伴； - * 他们的身份标识是一个或者是多个，如何关联和映射； - * 不同身份标识对应的认证方式和可信源是什么； - * 通过何种应用进行接入，是web、api、还是native app； - * 如果进行服务的访问控制，是否需要根据以上给予不同的授权； - * 是否需要增强的身份，给予的认证有效期； - * 多个应用之间的认证是否共享，即SSO； - * 多个应用之间的身份是否关联等等 - * 否涉及到敏感信息的操作，如有是否符合了法规； - * 当用户登出式，会发生哪些事件； - * 需要满足哪些合规性的需求。 - - ## 本章关键点回顾 现代用户希望在使用应用程序时获得无摩擦、设计良好的体验。身份管理应该帮助他们快速访问应用程序，而不是妨碍他们。为了实现这一点，开发人员面临许多问题，需要在开发身份管理时对各种可用选项进行规划。下一章将帮助您了解身份管理的组件， 通过覆盖身份生命周期的事件来解决问题。 diff --git a/docs/modernidentity/ChapterThree.md b/chapterthree.md similarity index 81% rename from docs/modernidentity/ChapterThree.md rename to chapterthree.md index 3542c2a..3e6f439 100644 --- a/docs/modernidentity/ChapterThree.md +++ b/chapterthree.md @@ -12,7 +12,7 @@ 第一阶段：石器时代，各个应用使用独立的身份体系、独立进行认证和存储身份，后来基于Cookie进行内部应用的单点登录。 -第二阶段，企业内部的应用越来越多，身份管理成为企业头痛的问题。2003年为了解决企业应用的联合认证的问题，微软联合、IBM等传统互联网巨头发起了基于WS*系列标准之上构建的WS-Federation1.1版本，但这一协议因为过于重，除了得到微软的积极拥护以外，其他软件厂商响应屈指可数。因而，2005年，SAML2.0横空出式，因为其协议的相对WS-Fed更为简洁明了，更因为适逢SaaS应用的发展，得到了一种SaaS厂商的支持。这也就是为何大家看到国外的SaaS平台基本上都继承了使用SAML的这一优良传统。 +第二阶段，企业内部的应用越来越多，身份管理成为企业头痛的问题。2003年为了解决企业应用的联合认证的问题，微软联合、IBM等传统互联网巨头发起了基于WS\*系列标准之上构建的WS-Federation1.1版本，但这一协议因为过于重，除了得到微软的积极拥护以外，其他软件厂商响应屈指可数。因而，2005年，SAML2.0横空出式，因为其协议的相对WS-Fed更为简洁明了，更因为适逢SaaS应用的发展，得到了一种SaaS厂商的支持。这也就是为何大家看到国外的SaaS平台基本上都继承了使用SAML的这一优良传统。 第三阶段，随着互联网、移动互联网的相继爆发，OpenID和Oauth应运而生，并且得到广泛的应用。在2012年以前，互联网之前的应用之间的信息交互较少。一方面互联网爆发式增长，让资源相互调用的需求迅猛增长，这也促进了Oauth2.0的诞生，同时，因为Oauth2.0，也让互联网应用之间的交互更加的蓬勃。 @@ -20,13 +20,13 @@ ![3-1-ID Protocol History.jpg](https://i.loli.net/2021/07/16/k9B2tZXmljREhUg.jpg) -## 石器时代-独立存储身份 +## 石器时代-独立存储身份 在石器时代的计算机应用程序中，每个应用程序通常实现自己的身份存储库、身份验证和授权。大型企业公司通常有核心业务应用程序，如财务和库存控制系统，也许还有一些生产力应用程序。每个应用程序通常都有自己的专用数据库或其他存储，其中存储了用户身份、凭据和用户配置文件数据，每个应用程序都会提示用户登录，然后根据自己的用户配置文件存储库验证用户的凭据信息。这意味着员工可能需要为每个应用程序记住不同的用户名和密码。这也意味着，如果用户配置文件中的某个元素发生了更改，则必须在多个应用程序中进行配置文件更改。当然，如果一家公司有许多应用程序，这种情况就不会可靠地发生，因此用户配置文件数据在各个系统中总是不同步。当只有几个应用程序时，用户对数据完整性问题的恼怒和必须记住大量密码就足够糟糕了。然而，随着企业中应用程序数量的增长，让每个应用程序实现自己的筒仓式身份存储库和身份验证解决方案很快就变得难以支撑。 这种孤立的方法目前仍在许多面向消费者的场景中使用，其中用户通过提供特定于应用程序的用户名和密码进行注册。如果一个用户在多个站点上重复使用同一个密码，任何一个站点上的泄露都可能使该用户的数据在其他站点上受到威胁。如果用户为每个应用程序指定不同的密码，他们必须记住或安全地存储密码，或者依赖应用程序提供的帐户恢复过程的安全性。不管是哪种方式，消费者用户都会面临与企业用户之前经历的这种方法相同的一些不便。 -## 目录服务-集中存储身份 +## 目录服务-集中存储身份 随着时间的推移，为广泛的业务功能编写的软件越来越多。这促使人们需要一种更好的身份管理方法。许多公司实施目录服务，如LDAP或AD来存放和集中用户身份信息。目录服务针对频繁读取但很少修改的信息进行了优化，这通常适用于用户身份数据。应用程序能够使用目录服务来存储用户数据和凭据。应用程序还可以使用目录服务中的信息提示用户登录并验证输入的凭据。面向企业环境的大型现场商业业务应用程序 包括对这种方法的支持。这种集中化的方法与按应用程序的孤立方法相比有了显著的改进。 @@ -34,8 +34,6 @@ 然而，尽管目录服务有很多优点，但也有一些缺点。目录服务本身并没有为用户维护任何类型的会话。目录服务中的身份信息集中通常意味着用户只有一个用户名和密码需要记住，但是用户仍然必须在每个应用程序的登录屏幕中输入凭据，因为每个应用程序都需要收集用户凭据并使用目录服务验证它们（在没有其他技术的情况下）。除了带来不便之外，这还将用户的密码暴露给应用程序。一个应用程序中的沦陷可能会使其他应用程序处于危险之中。当所有涉及的应用程序都在可信的公司网络中时，这种情况就已经够糟了。随着公司开始使用云应用程序，向云应用程序公开目录密码被其他人拥有会带来不可接受的风险。再一次，需要一个更好的解决方案！ - - ## 早期SSO服务器 几种类型的身份和访问管理（IAM）或单点登录（SSO）服务器提供了进一步的改进。早期的SSO服务器利用了目录服务中的身份信息，但在目录顶部提供了一个层维护会话以记住已通过身份验证的用户的服务。它们的工作方式多种多样，但在一种典型的方法中，应用程序可以将用户的浏览器重定向到SSO服务器，以便在那里对用户进行身份验证，并以安全的、预先确定的方式接收身份验证结果。如果用户在第一个应用程序的身份验证后不久访问了第二个应用程序，则第二个应用程序会将用户的浏览器重定向到SSO服务器，并且SSO服务器会检测到用户的现有会话，并以成功状态将其重定向回应用程序，而不会再次提示用户提供凭据。 @@ -46,7 +44,7 @@ ## 联合身份WS-Fed -WS-Federation（简称: WS-Fed )联合框架属于Web Services Security(简称: WS-Security、WSS: 针对web-service安全性方面扩展的协议标准集合) 的一部分。WS-Federation规范采用了XML以及其他Web服务标准，从而可以使开发者能够实现在不同环境下的网络安全管理及建立相互协调信赖关系的目的。 +WS-Federation（简称: WS-Fed \)联合框架属于Web Services Security\(简称: WS-Security、WSS: 针对web-service安全性方面扩展的协议标准集合\) 的一部分。WS-Federation规范采用了XML以及其他Web服务标准，从而可以使开发者能够实现在不同环境下的网络安全管理及建立相互协调信赖关系的目的。 ![3-1-WS-FED.jpg](https://i.loli.net/2021/07/16/Cyv9SudNtDYx32w.jpg) @@ -58,46 +56,33 @@ WS-Fed可用于完成从身份提供者到服务提供者的联合单点登录 而对于互联网或是SaaS服务厂商，更愿意选择SAML。 - - ## 联合身份 SAML 2.0 -SAML 2.0在2005年三月正式代替SAML 1.1成为OASIS标准。来自超过24个公司及团体的大约30人参与了SAML 2.0的创建。尤其是，自由联盟将身份联合框架规范（ID-FF）贡献给OASIS，后者成为了SAML 2.0规范的基础。 +SAML 2.0在2005年三月正式代替SAML 1.1成为OASIS标准。来自超过24个公司及团体的大约30人参与了SAML 2.0的创建。尤其是，自由联盟将身份联合框架规范（ID-FF）贡献给OASIS，后者成为了SAML 2.0规范的基础。 SaaS应用程序的爆炸式增长给身份管理带来了挑战转眼间，企业纷纷采用SaaS服务，使得IT部门对于SaaS应用的身份管理力不从心，在SaaS应用程序中通常没有管理员工身份的好方法。对于一家公司来说，很难管理其员工在SaaS系统中账户，同时，用户再次必须记住每个应用程序的密码。他们享受的跨内部应用程序的单点登录并没有扩展到外部SaaS应用程序。 -幸运的是，在2005年，发布了一个新的行业标准Saml2.0（securityassertion-Markup)。它提供了跨域和联合身份的web单点登录解决方案。这恰好适合于使用SaaS应用程序的企业, SAML 2.0为需要在SaaS应用程序中更好地控制员工身份的企业提供了一个极好的解决方案。 +幸运的是，在2005年，发布了一个新的行业标准Saml2.0（securityassertion-Markup\)。它提供了跨域和联合身份的web单点登录解决方案。这恰好适合于使用SaaS应用程序的企业, SAML 2.0为需要在SaaS应用程序中更好地控制员工身份的企业提供了一个极好的解决方案。 -SaaS应用程序可以将企业用户重定向回企业身份验证服务（称为身份提供者（IdP））进行身份验证。身份联合基于网络跨域的单点登录(SSO)， 以便于减少向一个用户分发多个身份验证令牌的管理开销。用户也只需记住一个用户名/密码，而无需反复登录。无论是对内部和外部应用，Saml赋予企业一个集中控制点，如果需要，可以在企业身份提供者处快速关闭一个用户的访问权限。密码策略和多因素身份验证也可以在一个地方实现，通过这种方式，SAML2.0解决了企业的许多身份问题。 +SaaS应用程序可以将企业用户重定向回企业身份验证服务（称为身份提供者（IdP））进行身份验证。身份联合基于网络跨域的单点登录\(SSO\)， 以便于减少向一个用户分发多个身份验证令牌的管理开销。用户也只需记住一个用户名/密码，而无需反复登录。无论是对内部和外部应用，Saml赋予企业一个集中控制点，如果需要，可以在企业身份提供者处快速关闭一个用户的访问权限。密码策略和多因素身份验证也可以在一个地方实现，通过这种方式，SAML2.0解决了企业的许多身份问题。 尽管被广泛采用，但是Saml2.0并不是万能的。该协议被设计为覆盖许多场景，使得配置和实现变得复杂。虽然SAML2.0在企业环境中被广泛采用，但是没有一个可行的业务模型来解决面向消费者的场景。另一个限制是saml2.0只解决了身份验证问题，而没有解决API的授权问题。应用程序正在向基于微服务、API的体系结构发展，正如通常实现的那样，SAML2.0解决了对用户进行身份验证的问题，但对API授权没有帮助。 - - ## 互联网时代OpenID SAML2.0只在面向员工的场景中采用，消费者用户仍然被迫在每个面向消费者的网站上重新注册。一个新的行业组织成立，为它所谓的“以用户为中心”的身份创建了一个解决方案，并由此产生了一个称为OpenID的协议。 OpenID是一个去中心化的网上身份认证系统。对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者（identity provider, IdP）的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。OpenID既解决了注册问题而又不需要依赖于中心性的网站来确认数字身份。 - 与面向组织控制的身份提供者 （Saml2.0和WS-Fed）不同，OpenID则提供了面向用户控制的消费者身份的协议。一些大型的互联网公司，Yahoo、最初的OpenID协议并没有得到广泛的应用，但它确实强调了以用户为中心的身份解决方案的必要性，并为另一个名为OpenID Connect的协议奠定了基础，我们稍后将介绍这个协议。 - - +与面向组织控制的身份提供者 （Saml2.0和WS-Fed）不同，OpenID则提供了面向用户控制的消费者身份的协议。一些大型的互联网公司，Yahoo、最初的OpenID协议并没有得到广泛的应用，但它确实强调了以用户为中心的身份解决方案的必要性，并为另一个名为OpenID Connect的协议奠定了基础，我们稍后将介绍这个协议。 ## 互联网时代Oauth2.0 在介绍OpenID Connect协议之前，我们首先要了解下授权协议[Oauth](https://www.oauth.com)，它并非是一个认证的协议，而是一个授权的协议，即无法用来认证使用者的身份，而是在知道使用者身份以后来颁发对于该使用者的权限。 -OAuth开始于2006年11月，当时布莱恩·库克正在开发Twitter的OpenID实现。与此同时，社交书签网站Ma.gnolia需要一个解决方案允许使用OpenID的成员授权Dashboard访问他们的服务。这样库克、克里斯·梅西纳和来自Ma.gnolia的拉里·哈尔夫（Larry Halff）与戴维·雷科尔顿会面讨论在Twitter和Ma.gnolia API上使用OpenID进行委托授权。但他们讨论得出结论，认为OpenID没有完成API访问委托的开放标准。 -2007年4月，成立了OAuth讨论组，这个由实现者组成的小组撰写了一个开放协议的提议草案。来自Google的德维特·克林顿获悉OAuth项目后，表示他有兴趣支持这个工作。2007年7月，团队起草了最初的规范。随后，Eran Hammer-Lahav加入团队并协调了许多OAuth的稿件，创建了更为正式的规范。2007年10月, OAuth核心1.0最后的草案发布了。 -2008年11月，在明尼阿波利斯举行的互联网工程任务组第73次会议上，举行了OAuth的BoF讨论将该协议纳入IETF做进一步的规范化工作。这个会议参加的人很多，关于正式地授权在IETF设立一个OAuth工作组这一议题得到了广泛的支持。2010年4月，OAuth 1.0协议发表为[RFC 5849](https://datatracker.ietf.org/doc/html/rfc5849)，一个非正式RFC。 2012年10月，OAuth 2.0发布，正式发表为[RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749)。OAuth 2.0是OAuth协议的下一版本，但不向下兼容OAuth 1.0。OAuth 2.0关注客户端开发者的简易性，同时为Web应用、桌面应用、手机和智能设备提供专门的认证流程。 -Facebook的新的Graph API只支持OAuth 2.0，Google在2011年3月也宣布Google API对OAuth 2.0的支持，越来越多的互联网应用开始支持OAuth2.0。 - - - -## 云原生 OpenID Connect (OIDC) - +OAuth开始于2006年11月，当时布莱恩·库克正在开发Twitter的OpenID实现。与此同时，社交书签网站Ma.gnolia需要一个解决方案允许使用OpenID的成员授权Dashboard访问他们的服务。这样库克、克里斯·梅西纳和来自Ma.gnolia的拉里·哈尔夫（Larry Halff）与戴维·雷科尔顿会面讨论在Twitter和Ma.gnolia API上使用OpenID进行委托授权。但他们讨论得出结论，认为OpenID没有完成API访问委托的开放标准。 2007年4月，成立了OAuth讨论组，这个由实现者组成的小组撰写了一个开放协议的提议草案。来自Google的德维特·克林顿获悉OAuth项目后，表示他有兴趣支持这个工作。2007年7月，团队起草了最初的规范。随后，Eran Hammer-Lahav加入团队并协调了许多OAuth的稿件，创建了更为正式的规范。2007年10月, OAuth核心1.0最后的草案发布了。 2008年11月，在明尼阿波利斯举行的互联网工程任务组第73次会议上，举行了OAuth的BoF讨论将该协议纳入IETF做进一步的规范化工作。这个会议参加的人很多，关于正式地授权在IETF设立一个OAuth工作组这一议题得到了广泛的支持。2010年4月，OAuth 1.0协议发表为[RFC 5849](https://datatracker.ietf.org/doc/html/rfc5849)，一个非正式RFC。 2012年10月，OAuth 2.0发布，正式发表为[RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749)。OAuth 2.0是OAuth协议的下一版本，但不向下兼容OAuth 1.0。OAuth 2.0关注客户端开发者的简易性，同时为Web应用、桌面应用、手机和智能设备提供专门的认证流程。 Facebook的新的Graph API只支持OAuth 2.0，Google在2011年3月也宣布Google API对OAuth 2.0的支持，越来越多的互联网应用开始支持OAuth2.0。 +## 云原生 OpenID Connect \(OIDC\) OpenID Connect是一种基于OAuth2.0规范的互操作认证协议，旨在提供身份验证、授权服务所需的关键功能。它使用简单的REST/JSON消息流，其设计目标是“使简单的事情变得简单和复杂的事情成为可能”。与任何先前的身份协议相比，开发人员集成起来是更加容易。 @@ -129,22 +114,15 @@ OIDC为用户、应用程序开发人员和身份提供者提供了好处。网 因此，使用行业标准身份协议有四个很好的理由！ - - 如果您对身份验证领域还比较陌生，那么首先学习这些协议可能会让您感到有点畏缩，并且可能会尝试自己发明一个更简单的身份验证方案。对此我们有两个词：“不要！”我们希望这本书能让你更容易理解如何使用这些协议。我们不想阻碍创新，但在认证领域的创新应该谨慎行事。你的创新最好把精力花在应用程序的核心价值主张上！ - - ## 本章重点回顾 +* 身份管理、身份验证和授权方法不断发展 随着时间的推移。早期的方法通常涉及特定于应用程序的标识和凭证。 +* 身份集中使用目录服务的数据启用了单个标识和凭据，但必须输入 由一个用户进入每个应用程序（在没有其他补充技术的情况下）。 +* 单点登录服务器提供了会话管理，因此用户可以一次登录并通过一次身份验证访问同一域中的多个应用程序。 +* Saml2.0和WS-Fed提供了跨域的单点登录和联合身份。 +* OpenID提供了一个面向消费者的解决方案。 +* OAuth公司 2.0提供了一个授权应用程序调用API的解决方案。 +* OIDC在OAuth之上提供了一个层 2.0用于对用户进行身份验证，并以标准格式向应用程序返回有关已验证用户的身份断言信息。 - -- 身份管理、身份验证和授权方法不断发展 随着时间的推移。早期的方法通常涉及特定于应用程序的标识和凭证。 -- 身份集中使用目录服务的数据启用了单个标识和凭据，但必须输入 由一个用户进入每个应用程序（在没有其他补充技术的情况下）。 - -- 单点登录服务器提供了会话管理，因此用户可以一次登录并通过一次身份验证访问同一域中的多个应用程序。 -- Saml2.0和WS-Fed提供了跨域的单点登录和联合身份。 -- OpenID提供了一个面向消费者的解决方案。 - -- OAuth公司 2.0提供了一个授权应用程序调用API的解决方案。 -- OIDC在OAuth之上提供了一个层 2.0用于对用户进行身份验证，并以标准格式向应用程序返回有关已验证用户的身份断言信息。 diff --git a/docs/modernidentity/ChapterTwo.md b/chaptertwo.md similarity index 99% rename from docs/modernidentity/ChapterTwo.md rename to chaptertwo.md index 3a8dcea..71e7593 100644 --- a/docs/modernidentity/ChapterTwo.md +++ b/chaptertwo.md @@ -28,8 +28,6 @@ 身份管理（IAM）系统是一组服务，支持创建、修改和删除身份和与其关联的帐户，以及访问资源所需的身份验证和授权。身份管理系统用于保护在线资源免受未经授权的访问，是应用安全模型的重要组成部分。 - - ## 身份生命周期里的事件 有了基本的定义，我们就可以继续讨论身份生命周期中的主要事件，如图 2-1所示. 本章我们将概述下在身份的生命周期当中会发生的事件，然后在后续章节中更深入地探讨每一个事件。事实上，基于事件去管理身份也是现代化的身份管理系统的主要思想。 @@ -42,11 +40,9 @@ 我们谈到的注册，通常是指用户，通过一个表单形式的注册页面，填写身份的属性信息，来生成一个账户。身份的供给实际上包含了一个更广泛的创建账户的范畴，身份供给可以通过让用户注册、从已有的系统中导入标识信息或利用已有系统的外部标识服务来完成，管理人员通过手工录入的方式来创建。无论使用何种机制，身份供给的目标都是建立一个具有关联身份属性数据的帐户。这涉及到获取或为用户实体分配身份的唯一标识符（如果需要进一步的分离，可以选择性的创建帐户的唯一标识符，这一标识符不同于身份的唯一标识符）、根据账户标识符创建帐户以及将身份相关的属性与该帐户相关联。 -例如，一个名为Alice的用户希望使用一些网上银行服务。爱丽丝可以通过填写账户登记表在银行建立一个个人网上银行账户。银行在为Alice创建账户时，会要求她提供身份相关的信息，包括姓名、密码、身份证号、家庭住址、（经过验证的）电话号码、电子邮件地址。 - -Alice在这个银行可以为不同的业务创建多个在线账户，如理财的账户、股票资金托管的账户等等。除此之外，Alice如果是个小企业主，Alice还可以使用自己公司的信息，如企业营业执照号码、税号、公司地址等信息，结合个人的身份信息，在银行创建自己企业的企业账户。 - +例如，一个名为Alice的用户希望使用一些网上银行服务。爱丽丝可以通过填写账户登记表在银行建立一个个人网上银行账户。银行在为Alice创建账户时，会要求她提供身份相关的信息，包括姓名、密码、身份证号、家庭住址、（经过验证的）电话号码、电子邮件地址。 +Alice在这个银行可以为不同的业务创建多个在线账户，如理财的账户、股票资金托管的账户等等。除此之外，Alice如果是个小企业主，Alice还可以使用自己公司的信息，如企业营业执照号码、税号、公司地址等信息，结合个人的身份信息，在银行创建自己企业的企业账户。 ## 身份映射（Mapping） @@ -66,8 +62,6 @@ Alice在银行建立了在线身份和账户后，就可以访问银行的网银 Alice可能首先使用用户名和密码登录，并能够在银行网站上查看她的帐户余额。如果Alice试图从账户中转出资金，则要求输入更强大的身份验证因素，才能成功执行该操作，比如，通过输入在银行登记过的手机收到的一次性动态码，或者进行动态的人脸识别，以确保请求转账业务的用户是本次操作帐户的所有者。 - - ## 身份认证状态（State） 身份认证状态（State），通常来讲，一个身份系统，基础的应该涉及到集中基础的状态，包括用户不存在、用户名或密码错误、认证成功等三种状态。但是如果考虑更安全的因素，认证的状态则要复杂的多，最基础的是用户的么密码是否过期，密码是否符合复杂度的要求，如果使用了一个简单的或者临时密码，则要求用户设置一个新的符合复杂性要求的密码。如果使用了MFA的多因素认证，则会涉及到更多的状态，如MFA是否登记，MFA在当前的认证流程中是否必须，MFA的挑战是否通过。只有通过了所有的安全的因素状态，系统才能给予认证成功，创建该用户的登录成功的会话。 @@ -82,8 +76,6 @@ Alice可能首先使用用户名和密码登录，并能够在银行网站上查 Alice的零售银行应用程序提供对其银行账户的访问，可能只允许相对较短的会话（以分钟为单位）。银行提供的另一种不太敏感的服务，如投资时事通讯，可能允许更长的会话时间，以小时或天为单位。每次Alice对任何一个应用程序发出请求时，应用程序都需要检查她最近是否对请求的事务进行了足够的身份验证。如果是这样，她可以继续而不需要再次验证。如果距离上次身份验证的时间超出了会话限制，她则将不得不再次进行身份验证。 - - ## 单点登录（SSO） 只需要通过一次认证，就可以访问所有授权的应用系统。单点登录（Single sign-on，SSO）是现代IT必备的一项基础功能，让用户和IT管理人员更加轻松应对工作需求。 @@ -94,8 +86,6 @@ Alice的零售银行应用程序提供对其银行账户的访问，可能只允 当Alice访问她的银行网站时，单点登录就可以让其方便地访问多个银行服务。比如，Alice在登录了网上银行的服务去查询账户余额之后，她在进行其他的一些被授权业务的访问，如理财资讯、积分管理等应用/服务时，她无需再次登录即可访问。 - - ## 注销（logout） 注销机制，是当用户在应用中完成需要处理的工作以后，应用程序提供的让用户终止当前会话一个方式。注销操作应该终止用户的应用程序会话，如果它们返回应用程序，则必须在被授予访问权限之前再次进行身份验证。如果实施了单点登录，那么可能有多个会话要终止，当用户从一个应用程序注销时，应该终止哪些会话是一个取决于整个系统的设计。 @@ -110,16 +100,12 @@ Alice的零售银行应用程序提供对其银行账户的访问，可能只允 例如，当Alice创建银行账户时，银行授权她的账户访问应用程序以查看存款账户，而且仅限于查看自己的存款账户而不能查看其他人的账户存款。如果她在银行没有股票资金托管账户，她的账户将无权进行股票交易资金的操作。Alice的授权表明她的帐户已被授予权限。对帐户的授权通常在创建帐户后完成，并且可能会随着时间的推移而更新。 - - ## 访问策略执行（Policy Enforcement） 一旦用户通过身份验证并与该帐户相关联，就必须严格的执行访问策略，以确保用户能够操作且仅限于之前被授予的权限。我们使用术语“访问策略执行”来匹配执行授权指定的访问策略。换句话说，授权指定允许用户或实体执行的操作，访问策略执行检查用户请求的操作是否符合授权使用的权限的约定。 当Alice登录到银行的网上银行应用程序并提出请求时，应用程序将检查她是否有权执行其提出请求。如果她试图访问非授权的业务，如没有开通理财账户，购买理财产品的请求将被拒绝，因为她无权访问这些服务。在这种情况下，应用程序可能会显示一条消息，指示不允许她查看该服务，其中可能包含有关如何申请开通该服务的信息。 - - ## 账户管理和恢复（Account Management） 在身份的整个生命周期中，可能需要更改用户身份资料的各种属性。例如，用户可能需要更新其电子邮件地址或电话号码。在某些情况下，用户可能需要更新其姓名，或者定期更改其密码或认证过程中使用的移动设备。在公司中，可能会更新用户身份资料以反映新的职位、地址或权限（如角色）。帐户管理由允许用户和管理员查看和更新与身份关联的用户资料的属性的功能或流程组成。 @@ -132,8 +118,6 @@ Alice的零售银行应用程序提供对其银行账户的访问，可能只允 可能有一天需要取消账户。在这种情况下，必须取消设置用户的帐户和关联的身份信息，以确保没有人再可以使用它。取消设置的形式可以是完全删除帐户和相关的身份信息，或者禁用帐户以保留信息用于审计目的。如果Alice在某个时候决定终止与银行的关系，她会要求关闭她的账户。银行将关闭她的储蓄账户，终止她的网上银行账户，这样她就不能再登录了。然而，为了确保该账户的所有行为和操作都是合规的，银行需要保留足够的历史信息，以满足后续的审计需求。 - - ## 本章关键点回顾 本章介绍了身份、帐户和相关标识的概念，以及它们存在期间发生的最典型事件，从认证、授权、会话和账户管理四个维度，分别进行了分类和每个类别下涉及到哪些事件，进行了详细的介绍。在接下来的章节中，我们将从身份管理的历史开始，逐步深入了解每个事件的更多细节。 diff --git a/docs/.nojekyll b/docs/.nojekyll deleted file mode 100644 index 8b13789..0000000 --- a/docs/.nojekyll +++ /dev/null @@ -1 +0,0 @@ - diff --git a/docs/CNAME b/docs/CNAME deleted file mode 100644 index 26f82a0..0000000 --- a/docs/CNAME +++ /dev/null @@ -1 +0,0 @@ -docs.oneauth.cn \ No newline at end of file diff --git a/docs/README.md b/docs/README.md deleted file mode 100644 index 875b870..0000000 --- a/docs/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# 这是一本关于如何做好身份管理的书 -> This book talk about how to build a morden identity. - -[开始阅读](/modernidentity/) diff --git a/docs/_coverpage.md b/docs/_coverpage.md deleted file mode 100644 index 27f4c65..0000000 --- a/docs/_coverpage.md +++ /dev/null @@ -1,9 +0,0 @@ - - -![logo](pics/logo.png) - -# OneAuth 3.5 -> 让身份更简单、更安全 - -[Get Started](/modernidentity/) -[GitHub](https://github.com/OneAuth2/OneAuth) diff --git a/docs/_navbar.md b/docs/_navbar.md deleted file mode 100644 index 1e0f91d..0000000 --- a/docs/_navbar.md +++ /dev/null @@ -1,3 +0,0 @@ - -* [主页](http://120.26.84.189) -* [现代身份构建指南](/modernidentity/) diff --git a/docs/index.html b/docs/index.html deleted file mode 100644 index 5ffeaca..0000000 --- a/docs/index.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - - OneAuth - - - - - - - -
- - - - - - - diff --git a/docs/modernidentity/README.md b/docs/modernidentity/README.md deleted file mode 100644 index ebb2c50..0000000 --- a/docs/modernidentity/README.md +++ /dev/null @@ -1,6 +0,0 @@ -# 现代身份构建指南 - -> An awesome identity book. - - - diff --git a/docs/modernidentity/_sidebar.md b/docs/modernidentity/_sidebar.md deleted file mode 100644 index a621204..0000000 --- a/docs/modernidentity/_sidebar.md +++ /dev/null @@ -1,16 +0,0 @@ - - -* [现代身份构建指南](modernidentity/ "现代身份构建指南") - * [引言](modernidentity/Introduction.md "引言") - * [第一章 现代身份管理的挑战](modernidentity/ChapterOne.md ) - * [第二章 身份的生命周期](modernidentity/ChapterTwo.md ) - * [第三章 身份演进的历史](modernidentity/ChapterThree.md ) - * [第四章 身份的供给/生成](modernidentity/ChapterFour.md ) - * [第五章 API安全的成熟度模型](modernidentity/ChapterFive.md ) - * [第六章 深入学习Oauth2.0](modernidentity/ChapterSix.md ) - * [第七章 深入学习OIDC](modernidentity/ChapterSeven.md ) - * [第八章 深入学习SAML2.0](modernidentity/ChapterEight.md ) - * [第九章 授权与访问策略执行](modernidentity/ChapterNine.md ) - * [第十章 身份认证会话](modernidentity/ChapterTen.md ) - * [第十一章 SSO单点登录](modernidentity/ChapterEleven.md ) - * [第十二章 身份认证增强](modernidentity/ChapterTwelve.md ) diff --git a/docs/pics/2-1-IdentityLifecycle.jpg b/docs/pics/2-1-IdentityLifecycle.jpg deleted file mode 100644 index 768cd7a..0000000 Binary files a/docs/pics/2-1-IdentityLifecycle.jpg and /dev/null differ diff --git a/docs/pics/5-1 API Security Model.png b/docs/pics/5-1 API Security Model.png deleted file mode 100644 index 565c9c1..0000000 Binary files a/docs/pics/5-1 API Security Model.png and /dev/null differ diff --git a/docs/pics/5-2 Level0.jpg b/docs/pics/5-2 Level0.jpg deleted file mode 100644 index ca51bb3..0000000 Binary files a/docs/pics/5-2 Level0.jpg and /dev/null differ diff --git a/docs/pics/5-2 Level1.jpg b/docs/pics/5-2 Level1.jpg deleted file mode 100644 index 1c9eace..0000000 Binary files a/docs/pics/5-2 Level1.jpg and /dev/null differ diff --git a/docs/pics/5-2 Level2.jpg b/docs/pics/5-2 Level2.jpg deleted file mode 100644 index 0f808bc..0000000 Binary files a/docs/pics/5-2 Level2.jpg and /dev/null differ diff --git a/docs/pics/logo.ico b/docs/pics/logo.ico deleted file mode 100644 index 3222cc2..0000000 Binary files a/docs/pics/logo.ico and /dev/null differ diff --git a/docs/pics/logo.png b/docs/pics/logo.png deleted file mode 100644 index 3fc914c..0000000 Binary files a/docs/pics/logo.png and /dev/null differ diff --git a/docs/pics/readme.md b/docs/pics/readme.md deleted file mode 100644 index 8b13789..0000000 --- a/docs/pics/readme.md +++ /dev/null @@ -1 +0,0 @@ - diff --git a/docs/modernidentity/ChapterEleven.md b/she-ji/chaptereleven.md similarity index 87% rename from docs/modernidentity/ChapterEleven.md rename to she-ji/chaptereleven.md index 5a93b20..ca64988 100644 --- a/docs/modernidentity/ChapterEleven.md +++ b/she-ji/chaptereleven.md @@ -1,4 +1,4 @@ -# 单点登录 +# 第十一章 单点登录SSO ## 什么是SSO 单点登录 @@ -28,19 +28,17 @@ ### SSO会话时长 -应配置SSO会话的长度，通常以最大超时和空闲超时来指定。当然，应用程序具有不同的敏感性，可以适应具有不同需求的应用程序需求，做出不同的响应。如果使用OIDC的应用程序需要用户更频繁地进行主动身份验证，则身份验证请求中的“max_age”参数可用于指定自用户上次主动身份验证以来所允许的最长时间（以秒为单位），通常比身份提供程序会话的时长要短。如果身份验证请求中的“max_age”值小于用户上次身份验证后经过的时间，则使用此参数要求身份提供程序再次主动对用户进行身份验证。应用程序仍应检查ID令牌中的身份验证时间声明，以确保遵循了请求的“max_age”。 +应配置SSO会话的长度，通常以最大超时和空闲超时来指定。当然，应用程序具有不同的敏感性，可以适应具有不同需求的应用程序需求，做出不同的响应。如果使用OIDC的应用程序需要用户更频繁地进行主动身份验证，则身份验证请求中的“max\_age”参数可用于指定自用户上次主动身份验证以来所允许的最长时间（以秒为单位），通常比身份提供程序会话的时长要短。如果身份验证请求中的“max\_age”值小于用户上次身份验证后经过的时间，则使用此参数要求身份提供程序再次主动对用户进行身份验证。应用程序仍应检查ID令牌中的身份验证时间声明，以确保遵循了请求的“max\_age”。 对于非敏感的应用，应用也可通过使用更长的应用会话时长，即便是身份提供程序会话已经结束，用户在应用程序中也可以保持活动状态， ### 多个身份服务提供商 -在某些情况下，会存在配置多个身份提供程序的身份源的情况，这时需要使用到身份代理实现SSO，身份代理应确保每个身份提供程序的用户只能登录到他们的被授予访问的应用程序。 -例如，如果一家公司有一个身份验证代理，其中一个身份提供者为员工配置，另一个为合作伙伴配置，则该配置应确保合作伙伴无法访问仅针对员工的应用程序。 -该场景如图11-2所示。在此示例中，应用程序A只能由身份提供程序A认证的用户访问。应用程序B只能由身份提供程序B认证的用户访问。由登录到身份提供程序B的用户建立的SSO会话则不允许访问应用程序A。 +在某些情况下，会存在配置多个身份提供程序的身份源的情况，这时需要使用到身份代理实现SSO，身份代理应确保每个身份提供程序的用户只能登录到他们的被授予访问的应用程序。 例如，如果一家公司有一个身份验证代理，其中一个身份提供者为员工配置，另一个为合作伙伴配置，则该配置应确保合作伙伴无法访问仅针对员工的应用程序。 该场景如图11-2所示。在此示例中，应用程序A只能由身份提供程序A认证的用户访问。应用程序B只能由身份提供程序B认证的用户访问。由登录到身份提供程序B的用户建立的SSO会话则不允许访问应用程序A。 ![11-2 Multi IDP.png](https://i.loli.net/2021/09/08/Tg3KNLdhYPVFDue.png) -
11-2 IDP 代理
+11-2 IDP 代理 ### 认证机制 diff --git a/docs/modernidentity/ChapterNine.md b/she-ji/chapternine.md similarity index 90% rename from docs/modernidentity/ChapterNine.md rename to she-ji/chapternine.md index e848134..876abf7 100644 --- a/docs/modernidentity/ChapterNine.md +++ b/she-ji/chapternine.md @@ -1,4 +1,4 @@ -# 授权与访问策略执行 +# 第九章 授权与访问策略执行 前面的第五章介绍了API访问的安全，以及第六章和第七章分别介绍了用户授权、OIDC的协议，那么二者如何结合，共同保障应用、API和数据的安全，本章节将介绍如何通过授权来保障API访问策略的执行。 @@ -14,8 +14,6 @@ ![9-1 AuthZ and Police Enforcement.jpg](https://i.loli.net/2021/07/20/XDnzPT7K6ptyY48.jpg) - - ## 控制级别 授权和访问策略强制可分别指定和应用于不同的级别： @@ -24,8 +22,6 @@ * 级别2–实体可以在应用程序或API中使用哪些功能 * 级别3—实体可以访问或操作的数据 - - ### 级别1-应用或API 在最高级别，授权和访问策略实施可以控制实体是否有权访问应用程序或API。这种用例经常出现在公司环境中。如8-1所示，运营团队中的员工可能没有访问公财务系统的权限。这一级别的策略实施可以在应用程序内处理，也可以由应用程序前面的实体处理， @@ -37,21 +33,18 @@ 功能级授权和访问策略实施控制实体在应用程序或API中可以做什么。例如，财务部门的初级会计职员可能可以访问公司会计系统并输入个别日记账分录，但不能执行月末结账。这种级别的授权和访问策略实施往往是特定于应用程序的。它可以利用存储在身份和授权系统中的用户信息，例如身份系统中的角色或组，但通常在应用程序或API的逻辑中强制执行。 ### 第3级-数据访问 + 第三级授权和访问政策执行规定了对特定数据子集的访问。如果功能级访问策略强制定义了实体可以执行的功能，则数据级访问策略将进一步限制对特定数据的访问。例如，在运营系统的订单应用中，可以在功能级别授权角色或组为“区域销售经理”的用户查看销售订单，但数据级访问策略将其限制在用户身份属性中的“销售区域”属性中所示的特定区域。数据级访问可以在应用程序或API内或底层存储层中强制执行。 ## 用户实体和应用实体的授权 -接下来，我们将介绍两种需要授权和访问策略实施的场景。 -第一个场景是关于如何控制用户（或实体）在应用程序中做什么，第二个是如何控制应用程序可以请求什么API。 +接下来，我们将介绍两种需要授权和访问策略实施的场景。 第一个场景是关于如何控制用户（或实体）在应用程序中做什么，第二个是如何控制应用程序可以请求什么API。 用户需要授权才能在应用程序中执行各种功能，应用程序可以根据用户的授权权限呈现应用程序的用户界面，这样就不会显示用户不能使用的功能。此外，当用户发出请求时，应用程序后端或API必须在执行请求之前检查用户是否具有请求所需的授权。 应用程序需要授权才能调用受保护的API。如果API上的内容归应用程序的用户所有，则访问需要用户的授权。这种情况经常出现在面向消费者的应用程序中。如果应用程序以自己的名义访问API中的内容，则授权服务器将根据授权服务器管理员先前配置的权限向应用程序授予授权。 -无论被授权的实体是什么，控制访问通常涉及三个步骤： -•授权和访问策略的规范定义。 -•向执行点提供授权信息（如果需要） -•执行点执行访问策略 +无论被授权的实体是什么，控制访问通常涉及三个步骤： •授权和访问策略的规范定义。 •向执行点提供授权信息（如果需要） •执行点执行访问策略 ### 用户授权 @@ -75,20 +68,12 @@ ![9-2 example for Authz Delvery .jpg](https://i.loli.net/2021/07/20/W91QBsgYuM42dRS.jpg) -
9-2授权传递
- -1.用户重定向到在OIDC OpenID提供程序处登录。 -2.ID令牌包括用户购买的订阅信息。 -3.ID Token中的订阅数据用于确定显示的电影列表。 -4.用户选择要观看的电影。 -5.应用程序后端检查用户所选电影的订阅级别。 - +9-2授权传递 +1.用户重定向到在OIDC OpenID提供程序处登录。 2.ID令牌包括用户购买的订阅信息。 3.ID Token中的订阅数据用于确定显示的电影列表。 4.用户选择要观看的电影。 5.应用程序后端检查用户所选电影的订阅级别。 在该示例中，ID令牌中关于用户的订阅级别的信息用于向用户显示他们有权观看的电影。它还用于强制执行访问策略。尽管前端将电影列表限制在用户可以观看的范围内，但恶意用户可能会找到绕过此限制的方法，因此访问策略强制检查是在应用程序后端进行的，无法绕过此检查。本例使用OIDC，但是使用SAML2.0的应用程序可以遵循类似的模型，从SAML2.0断言中获取授权数据。 - - #### 策略执行 在信任令牌声明的信息之前，需要验证令牌的有效性，声明的是未经篡改的真实性，一般流程如下： @@ -101,8 +86,6 @@ 请务必查看OpenID提供程序的文档，以了解实现它们所需的确切验证步骤。一旦ID令牌被验证，应用程序就可以使用令牌中的声明来执行访问策略。 - - ### 应用授权 授权和策略实施的第二种情况是应用程序调用API。 @@ -111,23 +94,23 @@ 代表用户调用API的应用程序请求由用户授权，代表自己调用API的请求由授权服务器基于配置的策略授权。此策略通常是在应用程序调用API之前配置的。除非应用程序或API的数量很大，否则策略规范通常通过指示授权调用特定API的特定应用程序以及可以访问哪些端点和操作来表示。如果使用OAuth2.0，策略可以按作用域来指定，例如“get:documents” -##### 授权 +**授权** OAuth2.0授权将其请求的作用域指定为授权请求的参数。例如，应用程序请求OpenID提供者的UserInfo端点的访问令牌来检索用户属性，可能会使用“scope=OpenID profile email”。 -作用域扮演着非常重要的角色。如果没有声明，作用域只是一个字符串列表，其中包含作用域标记或作用域名称。示例：scope=“doc_read doc_write openid email”。 +作用域扮演着非常重要的角色。如果没有声明，作用域只是一个字符串列表，其中包含作用域标记或作用域名称。示例：scope=“doc\_read doc\_write openid email”。 -将作用域scope参数看作访问范围是种不错的方式，也就是说，它列出了客户需要访问的内容，可以用于粗粒度授权，以决定是否允许客户机查询API。但是，即使令牌中存在doc_read的作用域，我们也不知道应该允许它读取哪个文档（doc）。为了进一步说明，以OpenID Connect为例，它将作用域定义为一组声明的集合。因此，“email” Scope令牌定义为“email”和“email is verified”声明。声明具有与其关联的值，而作用域标记只是一个名称，这意味着作用域只是一组声明的打包，例如OIDC中的Profile，具有如下的结构： +将作用域scope参数看作访问范围是种不错的方式，也就是说，它列出了客户需要访问的内容，可以用于粗粒度授权，以决定是否允许客户机查询API。但是，即使令牌中存在doc\_read的作用域，我们也不知道应该允许它读取哪个文档（doc）。为了进一步说明，以OpenID Connect为例，它将作用域定义为一组声明的集合。因此，“email” Scope令牌定义为“email”和“email is verified”声明。声明具有与其关联的值，而作用域标记只是一个名称，这意味着作用域只是一组声明的打包，例如OIDC中的Profile，具有如下的结构： ![9-3 OIDC Profile Token.png](https://i.loli.net/2021/07/20/q7OI4NyCDo18seE.png) -
9-3 OIDC Profile
+9-3 OIDC Profile 事实上每个OpenID声明都与一个作用域相关联，如下图所示。 ![9-4 OIDC Scope.png](https://i.loli.net/2021/07/20/2irTDLGOSZXUMo4.png) -
9-3 OIDC Scopes
+9-3 OIDC Scopes 这种定义的方式可以推广到任意作用域和声明，当涉及API访问时，这将变得非常有用。 @@ -141,11 +124,7 @@ OAuth2.0授权将其请求的作用域指定为授权请求的参数。例如， API必须验证访问令牌并执行访问策略，以确保在响应之前允许应用程序的请求。验证和获取有关访问令牌的信息的步骤将因授权服务器对访问令牌的实现而异。您应该查看授权服务方文档，以了解有关如何验证它发出的任何令牌的详细信息。一旦验证了访问令牌，API就可以使用令牌中的信息（如果允许的话，包括任何自定义声明）在响应请求之前执行其访问策略强制。 - - ## 本章重点回顾 授权涉及特权的授予，而访问策略强制是在请求资源时进行的检查，以验证请求者是否已被授予请求所需的特权。授权和访问策略实施可用于控制用户在应用程序中可以做什么，以及应用程序是否可以向API发出请求。用户授权可基于用户配置文件中的静态因素和/或身份验证时评估的动态因素，两者都可以通过安全令牌传递给应用程序。应用程序授权可以基于用户或授权服务器批准的作用域，并在传递给应用程序并用于调用API的访问令牌中显示。在下一章中，我们将讨论一个示例应用程序，以及它如何使用OIDC和OAuth 2.0来授权对API的访问。 - - diff --git a/docs/modernidentity/ChapterTen.md b/she-ji/chapterten.md similarity index 90% rename from docs/modernidentity/ChapterTen.md rename to she-ji/chapterten.md index f3a3b74..35c2647 100644 --- a/docs/modernidentity/ChapterTen.md +++ b/she-ji/chapterten.md @@ -1,4 +1,4 @@ -# Sessions 会话 +# 第十章 Sessions 会话 用户在一段时间内与应用程序的交互称为会话。Session代表浏览器与服务器的一次会话过程，这个过程是连续的，也可以时断时续的。 @@ -36,13 +36,10 @@ ## 多处会话 -一个用户可能在不同的解决方案组件之间有多个会话。用户可以在一个或多个应用程序中拥有会话。如果应用程序将身份验证委托给身份提供程序，则该身份提供程序可以为用户提供会话。如果应用程序将身份验证委托给身份验证代理，而身份验证代理又将身份验证委托给远程身份提供商，例如社交身份提供商或企业身份提供商，则可能存在三个架构层，其中都会存在会话。 -图10-2显示了三种不同的体系结构模型以及可能存在认证会话的位置。 +一个用户可能在不同的解决方案组件之间有多个会话。用户可以在一个或多个应用程序中拥有会话。如果应用程序将身份验证委托给身份提供程序，则该身份提供程序可以为用户提供会话。如果应用程序将身份验证委托给身份验证代理，而身份验证代理又将身份验证委托给远程身份提供商，例如社交身份提供商或企业身份提供商，则可能存在三个架构层，其中都会存在会话。 图10-2显示了三种不同的体系结构模型以及可能存在认证会话的位置。 ![10-1 Sessions Type.jpg](https://i.loli.net/2021/09/08/fSRA3zbr9ijXgsP.jpg) - - ## 会话持续时间 为用户建立的每个会话可以在不同的时间因各种原因终止。除了用户主动退出会话，会话会被终止。其他情况下，如会话的时间如果超过最大的时长限制，不管用户是否活动，会话可能会被终止。用户如果长时间没有活动，会话的空闲时间超过了会话空闲时间限制，会话也会被终止。 @@ -65,7 +62,7 @@ 当用户的应用程序会话到期时，应用程序可能希望用户能够续订会话。它可以通过将用户重定向回身份提供者来实现这一点。如果用户没有有效的会话，身份提供者可以对用户进行身份验证，并根据应用程序身份验证请求中的参数将新的安全令牌返回给应用程序。如果用户的身份提供程序会话仍然有效，则用户无需重新验证，应用程序将根据用户的现有会话接收新的安全令牌。然后，应用程序可以在续订用户的应用程序会话时使用新安全令牌中的信息。 -应用程序可以在身份验证请求中使用参数来抑制或强制活动身份验证。例如，如果自用户上次主动身份验证以来经过了一定的时间，则可能需要进行重新身份验证。在OIDC协议中，可以将可选的“prompt”参数添加到身份验证请求中，以强制或禁止OpenID提供者上的弹出或者禁止身份验证。可选的“max_age”参数可用于控制用户在通过认证后的最长使用时间，使用max_age的应用程序仍应检查ID令牌中的auth_time声明，以确保遵循了请求的max_age。如果OpenID提供程序具有相对较长的最大或空闲时间，但是特定应用程序希望更加频繁地进行身份验证，那么使用max_age和auth_time就会非常的实用。使用SAML2.0，应用程序可以使用身份验证请求的“ForceAuthn”属性强制身份提供程序主动对用户进行身份验证。此类身份验证请求参数为应用程序提供了一定程度的控制，以控制当用户重定向到身份提供程序时，是否对其进行主动重新身份验证。 +应用程序可以在身份验证请求中使用参数来抑制或强制活动身份验证。例如，如果自用户上次主动身份验证以来经过了一定的时间，则可能需要进行重新身份验证。在OIDC协议中，可以将可选的“prompt”参数添加到身份验证请求中，以强制或禁止OpenID提供者上的弹出或者禁止身份验证。可选的“max\_age”参数可用于控制用户在通过认证后的最长使用时间，使用max\_age的应用程序仍应检查ID令牌中的auth\_time声明，以确保遵循了请求的max\_age。如果OpenID提供程序具有相对较长的最大或空闲时间，但是特定应用程序希望更加频繁地进行身份验证，那么使用max\_age和auth\_time就会非常的实用。使用SAML2.0，应用程序可以使用身份验证请求的“ForceAuthn”属性强制身份提供程序主动对用户进行身份验证。此类身份验证请求参数为应用程序提供了一定程度的控制，以控制当用户重定向到身份提供程序时，是否对其进行主动重新身份验证。 除了通过重定向的方式，为了改善用户体验。身份提供者可以支持检查用户会话状态的替代方法。如果用户在身份提供者处具有有效会话，则允许在不需要浏览器重定向的情况下续订应用程序会话。如果用户的身份提供程序会话不再有效，则可以重定向该用户以续订身份提供程序会话。 @@ -73,8 +70,7 @@ 除了更新会话外，应用程序可能还需要定期更新安全令牌。应用程序可能已收到ID令牌，也可能已收到用于调用API的访问令牌。应用程序可能希望定期请求新的ID令牌，以确保其对经过身份验证的用户具有最新的声明。应用程序以前请求的访问令牌已经过期，可能希望请求一个新的访问令牌，因为它需要调用一个API。在许多情况下，尤其是对于公共客户机，发行到期时间较短的访问令牌并在需要时更新令牌被认为是一种最佳做法，因此在用户会话存在的整个过程中都可能需要新令牌。 -，在应用程序会话期间，根据应用程序的类型，应用程序可以使用不同的机制更新ID令牌或访问令牌。传统Web应用程序和本机应用程序可能能够获取刷新令牌以用于续订ID令牌和/或访问令牌，但是，这样做并不是必须的。**使用刷新令牌续订令牌可避免中断用户体验，但是通过后端的刷新令牌请求通道请求ID或访问令牌，可能不会更新身份提供程序的会话cookie，从而导致更快的空闲超时**。 -作为公共客户端实现的单页应用（SPA）程序，无法安全地存储和处理刷新令牌，因此必须使用不依赖刷新令牌的方法，除非其授权服务器对刷新令牌的泄漏风险采取了安全措施（如使用刷新令牌轮换或具有使用约束条件的刷新令牌）。不依赖刷新令牌的应用程序接收刷新令牌可以在需要新令牌时将用户重定向到OpenID提供程序。如果用户具有有效会话，则应用程序将接收新令牌。如果用户没有有效会话，请求将根据需要触发身份验证和同意。即使是使用刷新令牌的应用程序，也可能希望定期使用重定向方法来更新身份提供程序的会话cookie和空闲超时。 +，在应用程序会话期间，根据应用程序的类型，应用程序可以使用不同的机制更新ID令牌或访问令牌。传统Web应用程序和本机应用程序可能能够获取刷新令牌以用于续订ID令牌和/或访问令牌，但是，这样做并不是必须的。**使用刷新令牌续订令牌可避免中断用户体验，但是通过后端的刷新令牌请求通道请求ID或访问令牌，可能不会更新身份提供程序的会话cookie，从而导致更快的空闲超时**。 作为公共客户端实现的单页应用（SPA）程序，无法安全地存储和处理刷新令牌，因此必须使用不依赖刷新令牌的方法，除非其授权服务器对刷新令牌的泄漏风险采取了安全措施（如使用刷新令牌轮换或具有使用约束条件的刷新令牌）。不依赖刷新令牌的应用程序接收刷新令牌可以在需要新令牌时将用户重定向到OpenID提供程序。如果用户具有有效会话，则应用程序将接收新令牌。如果用户没有有效会话，请求将根据需要触发身份验证和同意。即使是使用刷新令牌的应用程序，也可能希望定期使用重定向方法来更新身份提供程序的会话cookie和空闲超时。 然而，将用户重定向到OpenID提供方并返回会带来用户体验的挑战，有可能会中断用户体验。对于单页应用程序，这可能会导致用户的工作丢失，除非应用程序保存用户准备提交的数据，并在从OpenID提供方返回后恢复它。**一个改进是在应用程序中使用隐藏的iframe进行重定向，并将“prompt”参数设置为“none”，以避免中断用户体验。如果用户具有有效会话，则应用程序将接收新令牌。如果没有，应用程序将收到错误响应，并且可以再次重定向用户，而无需使用“prompt=none”选项触发身份验证。OpenID提供商应在提供SDK中包含相关的设计，使应用程序更容易执行此操作。** @@ -85,3 +81,4 @@ ## 本章重点回顾 应用程序在用户与应用程序交互期间为用户维护会话。如果应用程序将身份验证委托给外部身份提供程序，则在解决方案体系结构的不同层上，用户可能会有多个会话。为用户维护会话的每个组件可能有一种或多种类型的会话超时。会话是实现单点登录的关键因素。 + diff --git a/docs/modernidentity/ChapterTwelve.md b/she-ji/chaptertwelve.md similarity index 77% rename from docs/modernidentity/ChapterTwelve.md rename to she-ji/chaptertwelve.md index 27fccf3..c8fc3f8 100644 --- a/docs/modernidentity/ChapterTwelve.md +++ b/she-ji/chaptertwelve.md @@ -1,4 +1,4 @@ -# 强身份认证 +# 第十二章 强身份认证 不同的身份验证方法的认证强度并不相同。静态密码被认为是一种相对较弱的身份验证机制。目前大多数互联网的应用仍然在采用静态密码的方式来进行认证，当然，有很多涉及到更多的用户数据、用户隐私的应用、企业的数据，都在引入更强的身份验证形式。在本章中，我们将讨论静态密码的问题，以及如何引入更强的身份验证形式用于多因素身份验证和逐步增强身份验证。 @@ -14,7 +14,7 @@ 为了规避直接使用生物因素的风险，另一种方式也在推广当中，使用用户的签名进行挑战验证，将用户的私有加密密钥对安全封装在设备（如智能卡、硬件安全令牌或移动电话）中。希望认证用户的实体向认证器设备发送质询nonce，封装在设备中的密钥用于对质询nonce进行签名。对于多因素身份验证设备，用户必须输入PIN或提供生物特征因素以解锁设备，然后才能签署质询。认证实体接收来自具有已签名质询nonce的设备的消息，并使用先前注册的信息验证签名，以确定用户（受试者）是否拥有认证器设备。使用这种方法，身份验证基于拥有设备的密钥以及解锁设备的因素。 -值得注意的是，基于知识的身份验证（KBA）涉及回答安全问题，与密码具有类似的风险。答案可能被远程实体猜测或窃取，并在所有者不知情的情况下使用。可以对认证方法的强度进行分类，**其中一个示例分类方案是美国国家标准技术研究院NIST 800-63安全标准[i](https://pages.nist.gov/800-63-3/sp800-63b.html)，该标准定义了三个认证者保证级别的标准。目前国内尚没有对应的标准可以参考**。 +值得注意的是，基于知识的身份验证（KBA）涉及回答安全问题，与密码具有类似的风险。答案可能被远程实体猜测或窃取，并在所有者不知情的情况下使用。可以对认证方法的强度进行分类，**其中一个示例分类方案是美国国家标准技术研究院NIST 800-63安全标准**[**i**](https://pages.nist.gov/800-63-3/sp800-63b.html)**，该标准定义了三个认证者保证级别的标准。目前国内尚没有对应的标准可以参考**。 ### MFA 多因素认证 @@ -22,10 +22,9 @@ 使用多因素身份验证，当一个因素被破解后，其他的强因素可以降低整个系统的受损风险。如果身份验证需要输入静态密码以及手机生成的一次性密码，黑客将不得不窃取用户密码并解锁手机，以模拟用户并访问其帐户。因此，需要多个因素进行身份验证可以更有力地保证身份验证人是合法的帐户所有者。 -在某些情况下，授权策略可能需要多因素身份验证。并不是所有的情况下，都会要求多因素认证，可能会降低用户体验。 -在某些，仅当检测到异常情况（例如用户试图从新设备或非典型地理位置访问）时，才可能需要多因素身份验证。但是在某些企业环境可能需要多因素身份验证才能进行远程访问，甚至有的在办公室中访问也需要进行多因素身份验证才能获得更敏感的资源。对于访问敏感内容，可能需要每次都进行多因素的认证，例如管理员对生产云服务器的访问。 +在某些情况下，授权策略可能需要多因素身份验证。并不是所有的情况下，都会要求多因素认证，可能会降低用户体验。 在某些，仅当检测到异常情况（例如用户试图从新设备或非典型地理位置访问）时，才可能需要多因素身份验证。但是在某些企业环境可能需要多因素身份验证才能进行远程访问，甚至有的在办公室中访问也需要进行多因素身份验证才能获得更敏感的资源。对于访问敏感内容，可能需要每次都进行多因素的认证，例如管理员对生产云服务器的访问。 -选择解决方案的身份验证机制时，应考虑到所涉及的应用程序和数据的敏感性以及解决方案的可用性，因为用户可能会试图规避对于特定情况来说过于繁重或被认为过于苛刻的机制。**美国国家标准技术研究院关于身份的标准NIST800-63-3第6节，特别是第6.2节[ii]( https://pages.nist.gov/800-63-3/sp800-63-3.html#sec6)，展示了如何为部署的应用选择合适的认证保证级别的一个示例。（NIST特别出版物800-63B[iii](https://pages.nist.gov/800-63-3/sp800-63b.html)附带了每个认证保证级别的认证类型列表。** +选择解决方案的身份验证机制时，应考虑到所涉及的应用程序和数据的敏感性以及解决方案的可用性，因为用户可能会试图规避对于特定情况来说过于繁重或被认为过于苛刻的机制。**美国国家标准技术研究院关于身份的标准NIST800-63-3第6节，特别是第6.2节**[**ii**](https://pages.nist.gov/800-63-3/sp800-63-3.html#sec6)**，展示了如何为部署的应用选择合适的认证保证级别的一个示例。（NIST特别出版物800-63B**[**iii**](https://pages.nist.gov/800-63-3/sp800-63b.html)**附带了每个认证保证级别的认证类型列表。** ### 认证升级 @@ -39,14 +38,13 @@ ## 请求身份验证机制 -应用需要向身份提供者请求使用特定类别的身份验证机制来实现所需级别的身份验证保证。这可以通过身份验证上下文类引用来完成，身份验证上下文涉及多个因素，例如用于创建帐户的标识过程、防止凭据泄露的保护以及使用的身份验证机制。身份验证上下文类表示一组身份验证方法，身份验证上下文类引用是身份验证上下文类的标识符。 -以下各节解释应用程序如何请求特定的身份验证上下文类别，以及身份提供者如何提供声明以传递所使用的身份验证上下文类引用和/或身份验证机制。 +应用需要向身份提供者请求使用特定类别的身份验证机制来实现所需级别的身份验证保证。这可以通过身份验证上下文类引用来完成，身份验证上下文涉及多个因素，例如用于创建帐户的标识过程、防止凭据泄露的保护以及使用的身份验证机制。身份验证上下文类表示一组身份验证方法，身份验证上下文类引用是身份验证上下文类的标识符。 以下各节解释应用程序如何请求特定的身份验证上下文类别，以及身份提供者如何提供声明以传递所使用的身份验证上下文类引用和/或身份验证机制。 ### OIDC OIDC客户端可以使用认证请求的以下参数，按优先顺序请求一个或多个认证上下文类： -* acr_value–身份验证上下文类参考 +* acr\_value–身份验证上下文类参考 颁发给应用程序的ID令牌可以包含以下参数，以传递用于对ID令牌中引用的用户（主题）进行身份验证的身份验证上下文类和身份验证方法: @@ -57,7 +55,7 @@ OIDC客户端可以使用认证请求的以下参数，按优先顺序请求一 ### SAML2.0 -SAML2.0身份验证请求可以使用元素指定应用程序所需的身份验证上下文类。如果身份提供程序提供此信息，SAML2.0身份验证响应将在身份验证断言的元素中显示用于对用户进行身份验证的身份验证上下文类。应用程序（服务提供商）和身份提供商必须提前为不同的身份验证上下文类建立定义。文档“OASIS安全断言标记语言（SAML）V2.0的身份验证上下文”[vi](https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf)列出了几个可以使用的预定义身份验证上下文类。 +SAML2.0身份验证请求可以使用元素指定应用程序所需的身份验证上下文类。如果身份提供程序提供此信息，SAML2.0身份验证响应将在身份验证断言的元素中显示用于对用户进行身份验证的身份验证上下文类。应用程序（服务提供商）和身份提供商必须提前为不同的身份验证上下文类建立定义。文档“OASIS安全断言标记语言（SAML）V2.0的身份验证上下文”[vi](https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf)列出了几个可以使用的预定义身份验证上下文类。 ## 认证降级 @@ -69,22 +67,21 @@ SAML2.0身份验证请求可以使用元素指定应用 ## 本章重点回顾 -密码是一种相对较弱的身份验证形式，使用移动终端或多因素加密身份验证设备上生成的一次性密码被视为更强的形式。 -逐步身份验证是使用更强大的身份验证形式进行身份验证的行为，它将已经存在的身份验证会话提升到更高级别的身份验证保证。授权策略可能要求会话处于特定身份保证级别，以便访问敏感资源。 +密码是一种相对较弱的身份验证形式，使用移动终端或多因素加密身份验证设备上生成的一次性密码被视为更强的形式。 逐步身份验证是使用更强大的身份验证形式进行身份验证的行为，它将已经存在的身份验证会话提升到更高级别的身份验证保证。授权策略可能要求会话处于特定身份保证级别，以便访问敏感资源。 -OIDC和SAML 2.0都允许应用程序请求身份提供者使用特定的身份验证上下文类的身份验证机制对用户进行身份验证，并接收有关用于对用户进行身份验证的身份验证上下文类和/或身份验证方法的信息。 -通过缩短会话超时或注销来及时终止更高级别的会话是身份验证降级的推荐实现方式。 +OIDC和SAML 2.0都允许应用程序请求身份提供者使用特定的身份验证上下文类的身份验证机制对用户进行身份验证，并接收有关用于对用户进行身份验证的身份验证上下文类和/或身份验证方法的信息。 通过缩短会话超时或注销来及时终止更高级别的会话是身份验证降级的推荐实现方式。 ## 参考 -i. https://pages.nist.gov/800-63-3/sp800-63b.html +i. [https://pages.nist.gov/800-63-3/sp800-63b.html](https://pages.nist.gov/800-63-3/sp800-63b.html) -ii. https://pages.nist.gov/800-63-3/sp800-63-3.html#sec6 +ii. [https://pages.nist.gov/800-63-3/sp800-63-3.html\#sec6](https://pages.nist.gov/800-63-3/sp800-63-3.html#sec6) -iii.https://pages.nist.gov/800-63-3/sp800-63b.html +iii.[https://pages.nist.gov/800-63-3/sp800-63b.html](https://pages.nist.gov/800-63-3/sp800-63b.html) -iv.https://openid.net/specs/openid-connect-eap-acr-values-1_0.html +iv.[https://openid.net/specs/openid-connect-eap-acr-values-1\_0.html](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html) -v.https://datatracker.ietf.org/doc/html/draft-ietf-oauth-amr-values-04 +v.[https://datatracker.ietf.org/doc/html/draft-ietf-oauth-amr-values-04](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-amr-values-04) + +vi.[https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf](https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf) -vi.https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf \ No newline at end of file diff --git a/docs/modernidentity/Introduction.md b/xian-dai-shen-fen-jian-she-zhi-nan/introduction.md similarity index 95% rename from docs/modernidentity/Introduction.md rename to xian-dai-shen-fen-jian-she-zhi-nan/introduction.md index 0dc7ebd..402932b 100644 --- a/docs/modernidentity/Introduction.md +++ b/xian-dai-shen-fen-jian-she-zhi-nan/introduction.md @@ -1,7 +1,5 @@ # 引言 - - 云计算、移动互联网、IoT、5G 等一批新技术不断采用，线上的业务与日俱增。另一方面，网络安全的形式也愈加紧迫。 网络安全工作人员缺口巨大且不断扩大，根据网络安全劳动力研究报告，全球网络安全人才缺口已扩大至近 300 万。其中，亚太地区缺口最高，达到了214 万。在需要安全保护的在线服务和设备数量激增的今天，网络安全面临的严峻风险令人震惊。为了填补这一空白，除了通过高校和社会机构培养更多的人才以外。必须鼓励更多的人了解这一领域，包括非安全专业的技术人员，例如开发者，鼓励他们更多的理解安全，并为他们提供足够的学习资源，使他们能够在开发阶段有效地选择安全的架构和安全的开发模式。 @@ -22,7 +20,7 @@ 期望通过本书的对于身份的概述，能够帮助你开始理解身份安全，为你提供足够的背景知识，以为你更全面地了解身份安全做好铺垫。 -对于身份安全，涵盖的内容如此之广，也期望读者对我们遗漏的内容、理解偏差的内容以提供更正和反馈。我们将该书发布在docs.oneauth.com，同时可通过https://github.com/OneAuth2/Oneauth 访问，后续发现的任何错误欢迎大家反馈，对于一些错误的更正，也都将在该书的OneAuth GitHub repo中注明。 +对于身份安全，涵盖的内容如此之广，也期望读者对我们遗漏的内容、理解偏差的内容以提供更正和反馈。我们将该书发布在docs.oneauth.com，同时可通过[https://github.com/OneAuth2/Oneauth](https://github.com/OneAuth2/Oneauth) 访问，后续发现的任何错误欢迎大家反馈，对于一些错误的更正，也都将在该书的OneAuth GitHub repo中注明。 我们希望这本书和示例代码对您有用，并祝您的应用程序项目好运和安全。 diff --git a/docs/modernidentity/ChapterEight.md b/xie-yi/chaptereight.md similarity index 78% rename from docs/modernidentity/ChapterEight.md rename to xie-yi/chaptereight.md index 03aa382..c65211b 100644 --- a/docs/modernidentity/ChapterEight.md +++ b/xie-yi/chaptereight.md @@ -1,7 +1,6 @@ -# 深入学习SAML2.0 +# 第八章 深入学习SAML2.0 -众所周知，安全断言标记语言（SAML）2.0提供了两个重要特性：跨域单点登录（SSO）和身份联合。SAML2.0已被许多企业环境采用，因为它使企业能够让员工、客户和合作伙伴使用的应用程序将用户身份验证委托给集中的企业身份提供者。这为企业提供了一个身份管理和控制中心。如果您正在为大型企业客户编写应用程序，他们可能希望您的应用支持使用SAML2.0进行身份验证[](https://wiki.oasis-open.org/security/FrontPage)。 -在本章中，我们将概述SAML2.0，它的设计用来解决什么问题，以及SAML2.0中的跨域单点登录和身份联合特性。我们还将提供一个融合的解决方案，说明如何利用OIDC这样的较新协议，并且仍然有效地实现对SAML的支持。 +众所周知，安全断言标记语言（SAML）2.0提供了两个重要特性：跨域单点登录（SSO）和身份联合。SAML2.0已被许多企业环境采用，因为它使企业能够让员工、客户和合作伙伴使用的应用程序将用户身份验证委托给集中的企业身份提供者。这为企业提供了一个身份管理和控制中心。如果您正在为大型企业客户编写应用程序，他们可能希望您的应用支持使用SAML2.0进行身份验证。 在本章中，我们将概述SAML2.0，它的设计用来解决什么问题，以及SAML2.0中的跨域单点登录和身份联合特性。我们还将提供一个融合的解决方案，说明如何利用OIDC这样的较新协议，并且仍然有效地实现对SAML的支持。 ## 解决的问题 @@ -21,7 +20,6 @@ SAML规范定义了以下术语： * SAML断言–一种基于XML的消息，包含有关主题的安全信息。 * SAML Profile–定义如何将SAML消息用于业务用例（如跨域单点登录）的规范。 * 身份提供者–身份提供者是一个服务器，它在跨域单点登录的上下文中发布有关已验证主题的SAML断言。 - * 服务提供者–服务提供者将身份验证委托给身份提供者，并依赖于身份提供者在跨域单点登录上下文中发出的SAML断言中有关已验证主题的信息。 * 信任关系–SAML服务提供者和SAML身份提供者之间的协议，其中服务提供者信任身份提供者发布的断言。 * SAML协议绑定–描述如何将SAML消息元素映射到标准通信协议（如HTTP）上，以便在服务提供者和身份提供者之间进行传输。实际上，SAML请求和响应消息通常通过HTTPS发送，使用HTTP重定向或HTTP-POST，分别使用HTTP重定向和HTTP-POST绑定。 @@ -36,45 +34,40 @@ SAML规范定义了以下术语： ### 应用SP发起的SSO -跨域单点登录的最简单形式如图8-1所示。在此示例中，用户从服务提供商（SP）（应用程序）开始，因此称为“SP启动”流(该图描述了该场景，其中用户在身份提供者处没有现有的身份验证会话，因此必须进行身份验证）。 +跨域单点登录的最简单形式如图8-1所示。在此示例中，用户从服务提供商（SP）（应用程序）开始，因此称为“SP启动”流\(该图描述了该场景，其中用户在身份提供者处没有现有的身份验证会话，因此必须进行身份验证）。 ![8-1 SAML SP-Initiated.jpg](https://i.loli.net/2021/07/19/3n1IJDpqwYVevmM.jpg) -
8-1 SP发起的SSO
+8-1 SP发起的SSO 1. 用户向应用（Servie Provider）发起访问请求 -2. 应用向身份提供者(Identity provider)发出一个SAML Request请求，该请求通过浏览器进行重定向。 -3. 身份提供者(Identity provider)接下来将向用户发起身份验证。 +2. 应用向身份提供者\(Identity provider\)发出一个SAML Request请求，该请求通过浏览器进行重定向。 +3. 身份提供者\(Identity provider\)接下来将向用户发起身份验证。 4. 用户通过输入凭据进行身份验证。 -5. 身份提供者(Identity provider)使用包含SAML身份验证断言的SAML响应,通过用户的浏览器重定向回服务提供者（SP）。响应被发送到服务提供者的断言使用者服务（Assertion Consumer Service-ACS）的URL。 +5. 身份提供者\(Identity provider\)使用包含SAML身份验证断言的SAML响应,通过用户的浏览器重定向回服务提供者（SP）。响应被发送到服务提供者的断言使用者服务（Assertion Consumer Service-ACS）的URL。 6. 服务提供者（SP）使用并验证SAML响应，如果通过验证，响应用户的原始请求。 - - -### 身份服务IdP发起的SSO +### 身份服务IdP发起的SSO 图8-1显示了从服务提供者（应用程序）开始与用户的交互序列。这被称为应用发起的单点登录，因为用户在服务提供商（SP）发起交互。SAML还定义了另一个流程，称为“IdP initiated”-身份服务发起的SSO，其中用户从身份提供者（IdP）开始，如图8-2所示。在这种情况下，身份提供者使用SAML响应消息将用户的浏览器重定向到服务提供者，而服务提供者没有发送任何身份验证请求。在某些企业环境中，用户可以通过企业门户访问应用程序，从而可以使用这种流程。 -这种场景如下描述：当用户最初访问公司门户时，他们将被重定向到公司身份提供程序以登录。登录后，用户将返回到门户，并在门户上看到应用程序链接的菜单/图标。单击其中一个链接将用户重定向到身份提供程序，并将应用程序URL作为参数。身份提供程序检测到用户已经有一个经过身份验证的会话，并使用SAML响应消息将用户的浏览器重定向到应用程序，与SP initiated的情况相同。 -事实上，IdP发起的SSO，并不一定是需要门户，但是选择了使用门户是IdP发起SSO的一种常见方式。 +这种场景如下描述：当用户最初访问公司门户时，他们将被重定向到公司身份提供程序以登录。登录后，用户将返回到门户，并在门户上看到应用程序链接的菜单/图标。单击其中一个链接将用户重定向到身份提供程序，并将应用程序URL作为参数。身份提供程序检测到用户已经有一个经过身份验证的会话，并使用SAML响应消息将用户的浏览器重定向到应用程序，与SP initiated的情况相同。 事实上，IdP发起的SSO，并不一定是需要门户，但是选择了使用门户是IdP发起SSO的一种常见方式。 IdP发起的带有门户的流在企业中很有用，因为它提供了单点登录，并确保用户访问每个应用程序的正确URL，从而降低了用户被钓鱼的风险。IdP启动的流程如图7-2所示。（此图假设用户没有现有的身份验证会话，登录门户实际上是个SP发起SSO的流程，后半部分，用户访问SP是IdP发起SSO的流程。） ![8-2 SAML IdP-Initiated.jpg](https://i.loli.net/2021/07/19/1xYnSFjgClaWVKz.jpg) -
8-2 IdP发起的SSO
+8-2 IdP发起的SSO 1. 用户向门户发起访问请求 -2. 门户向身份提供者(Identity provider)发出一个SAML Request请求，该请求通过浏览器进行重定向。 -3. 身份提供者(Identity provider)接下来将向用户发起身份验证。 +2. 门户向身份提供者\(Identity provider\)发出一个SAML Request请求，该请求通过浏览器进行重定向。 +3. 身份提供者\(Identity provider\)接下来将向用户发起身份验证。 4. 用户通过输入凭据进行身份验证。 -5. 身份提供者(Identity provider)使用包含SAML身份验证断言的SAML响应,通过用户的浏览器重定向回门户。响应被发送到门户的断言使用者服务（Assertion Consumer Service-ACS）的URL。如果该断言通过门户服务的验证，门户展示用户可以访问的应用列表。 +5. 身份提供者\(Identity provider\)使用包含SAML身份验证断言的SAML响应,通过用户的浏览器重定向回门户。响应被发送到门户的断言使用者服务（Assertion Consumer Service-ACS）的URL。如果该断言通过门户服务的验证，门户展示用户可以访问的应用列表。 6. 用户点击要访问的应用的链接，该链接将通过浏览器重定向到身份服务者，同时将本次用户需要访问的应用的URL附带在参数中。 7. 身份服务者检查用户的Session是否还存在，如果存在，IdP使用包含SAML身份验证断言的SAML响应,通过用户的浏览器重定向回服务提供者（SP）。响应被发送到服务提供者的断言使用者服务（Assertion Consumer Service-ACS）的URL。 8. 服务提供者（SP）使用并验证SAML响应，如果通过验证，向用户展示该应用的页面。 - - ### 身份联邦 通过SAML，身份联合建立了在服务提供者（应用程序）和身份提供者之间使用的一致的标识符，以指向同一（用户）主体。这使得服务提供商能够将用户的认证委托给身份提供商，并接收具有身份声明的认证断言来判别用户。 @@ -83,7 +76,7 @@ IdP发起的带有门户的流在企业中很有用，因为它提供了单点 ![8-3 Identity Federation.jpg](https://i.loli.net/2021/07/19/fCneOhQEjwpis7k.jpg) -
8-3 身份联邦
+ 8-3 身份联邦 身份提供者的管理员向 Application 1和Application2的管理员提供身份服务有关其环境的元数据，二者使用元数据在Application1/2和身份提供者之间设置联合认证的配置。身份提供者将会向其配置的每个服务提供者发送断言，这些断言包含服务提供者（应用程序）的适当标识符和属性。 @@ -93,8 +86,6 @@ IdP发起的带有门户的流在企业中很有用，因为它提供了单点 服务提供者的身份和身份提供者之间的关系可以以不同的方式设置。在实践中，用户的电子邮件通常在服务提供商和身份提供商处被用作用户的标识符，但是这可能是有问题的，因为用户可能需要更改其电子邮件地址，并且它可能与隐私要求相冲突。可以在请求中动态请求特定标识符属性的使用，或者可以将身份提供者配置为向服务提供者发送特定标识符。身份提供者和服务提供者还可以使用用户的不透明内部标识符交换信息，该标识符在每侧映射到用户的概要文件。为每个联合体使用唯一标识符有利于隐私保护，并防止用户活动的关联，但在实践中并不常见，该方法需要在双方交换元数据并配置其基础结构以在服务提供者和身份提供者之间建立关系时设置。 - - ## 中间代理 身份验证中间代理的主要目的是为了支持多种身份验证协议和机制。有的客户希望他们的用户使用公司SAML身份提供者的认证服务。 @@ -105,35 +96,31 @@ IdP发起的带有门户的流在企业中很有用，因为它提供了单点 ![8-4-IDP Broker.jpg](https://i.loli.net/2021/07/19/VoqrRnTc1GymUFC.jpg) - - -
8-4 IdP中间代理
+8-4 IdP中间代理 ## 配置说明 表8-1和8-2列出了通常需要在服务提供者（应用程序）和身份提供者处配置的参数及其含义。 -| 参数 | 描述 | -| ------------------ | ------------------------------------------------------------ | -| SSO URL | 身份提供者的单点登录URL的入口，应用向该URL请求身份验证。 | -| Certificate | 来自身份提供者的证书。用于验证来自身份提供程序的SAML响应/断言上的签名，同时也可在应用发送加密请求时使用。某些提供程序允许两种用途使用不同的证书。 | -| Protocol binding | 指定发送请求时使用何种协议进行绑定。典型的使用HTTP-Redirect，或者 HTTP-POST 用于直接请求。 | -| Request signing | 用于指示是否对SAML身份验证请求进行数字签名，如果是，通过哪个签名算法。建议签名。 | -| Request encryption | 是否对SAML身份验证请求进行加密。 | - -
8-1 SAML认证 常用SP配置
+| 参数 | 描述 | +| :--- | :--- | +| SSO URL | 身份提供者的单点登录URL的入口，应用向该URL请求身份验证。 | +| Certificate | 来自身份提供者的证书。用于验证来自身份提供程序的SAML响应/断言上的签名，同时也可在应用发送加密请求时使用。某些提供程序允许两种用途使用不同的证书。 | +| Protocol binding | 指定发送请求时使用何种协议进行绑定。典型的使用HTTP-Redirect，或者 HTTP-POST 用于直接请求。 | +| Request signing | 用于指示是否对SAML身份验证请求进行数字签名，如果是，通过哪个签名算法。建议签名。 | +| Request encryption | 是否对SAML身份验证请求进行加密。 | -| 参数 | 描述 | -| ------------------ | ------------------------------------------------------------ | -| ACS URL | 身份提供者的单点登录URL的入口，应用向该URL请求身份验证。 | -| Certificate | 来自身份提供者的证书。用于验证来自身份提供程序的SAML响应/断言上的签名，同时也可在应用发送加密请求时使用。某些提供程序允许两种用途使用不同的证书。 | -| Protocol binding | 指定发送响应时使用何种协议进行绑定。典型的使用 HTTP-POST 。 | -| Request signing | 用于指示是否对SAML身份验证响应进行数字签名，如果是，通过哪个签名算法。签名是强制性的。 | -| Request encryption | 是否对SAML身份验证响应进行加密。 | - -
8-2 SAML认证 常用IDP配置
+8-1 SAML认证 常用SP配置 +| 参数 | 描述 | +| :--- | :--- | +| ACS URL | 身份提供者的单点登录URL的入口，应用向该URL请求身份验证。 | +| Certificate | 来自身份提供者的证书。用于验证来自身份提供程序的SAML响应/断言上的签名，同时也可在应用发送加密请求时使用。某些提供程序允许两种用途使用不同的证书。 | +| Protocol binding | 指定发送响应时使用何种协议进行绑定。典型的使用 HTTP-POST 。 | +| Request signing | 用于指示是否对SAML身份验证响应进行数字签名，如果是，通过哪个签名算法。签名是强制性的。 | +| Request encryption | 是否对SAML身份验证响应进行加密。 | +8-2 SAML认证 常用IDP配置 ## 本章重点回顾 @@ -155,11 +142,7 @@ SAML2.0为web单点登录和身份联合提供了行业标准解决方案。 一旦解决了身份验证，就需要授权和策略执行来控制用户可以做什么，这将在下一章中介绍。 - - ## 参考： -i: https://wiki.oasis-open.org/security/FrontPage - - +i: [https://wiki.oasis-open.org/security/FrontPage](https://wiki.oasis-open.org/security/FrontPage) diff --git a/docs/modernidentity/ChapterSeven.md b/xie-yi/chapterseven.md similarity index 62% rename from docs/modernidentity/ChapterSeven.md rename to xie-yi/chapterseven.md index 19660c2..3856b5e 100644 --- a/docs/modernidentity/ChapterSeven.md +++ b/xie-yi/chapterseven.md @@ -1,7 +1,6 @@ -# OpenID Connect +# 第七章 OpenID Connect -如前一章所述，OAuth2.0提供了一个框架，用于授权应用程序调用API，但不是为验证应用程序的用户而设计的。 -因为互联网的应用越来越多，不同的应用之间需要共享身份，亟需一个大家公认的标准来进行身份的共享。同时，因为技术的演进（微服务、云原生），对于API的授权需求越来越多。OAuth2.0的一些实现为此添加了专有的附加内容，但是需要一个标准的解决方案。OpenID Connect（OIDC）[i](https://openid.net/connect/) 协议在Oauth2.0之上提供了一个身份服务层，旨在允许授权服务器对应用程序的用户进行身份验证，并以标准的方式返回结果。在本章中，我们将更详细地描述OIDC解决的问题和应用程序如何使用OIDC对用户进行身份验证。 +如前一章所述，OAuth2.0提供了一个框架，用于授权应用程序调用API，但不是为验证应用程序的用户而设计的。 因为互联网的应用越来越多，不同的应用之间需要共享身份，亟需一个大家公认的标准来进行身份的共享。同时，因为技术的演进（微服务、云原生），对于API的授权需求越来越多。OAuth2.0的一些实现为此添加了专有的附加内容，但是需要一个标准的解决方案。OpenID Connect（OIDC）[i](https://openid.net/connect/) 协议在Oauth2.0之上提供了一个身份服务层，旨在允许授权服务器对应用程序的用户进行身份验证，并以标准的方式返回结果。在本章中，我们将更详细地描述OIDC解决的问题和应用程序如何使用OIDC对用户进行身份验证。 ## 解决的问题 @@ -11,16 +10,15 @@ OIDC协议旨在解决某些场景下，用户需要通过身份验证才能访 ![7-1 OIDC.jpg](https://i.loli.net/2021/07/16/Z9zF7KAjG8VlOPE.jpg) -
7-1 OIDC 概览
+7-1 OIDC 概览 -当用户访问应用程序时，它会将用户的浏览器重定向到实现OIDC的授权服务器。 OIDC将这样的授权服务器称为OpenID提供者(OpenID Provider)，我们将在本章中使用该术语。OpenID提供者与用户交互以验证他们的身份（假设他们还没有登录）。身份验证后，用户的浏览器将重定向回应用程序。应用程序可以请求在称为ID令牌的安全令牌中返回关于已验证用户的声明。或者，它可以请求Oauth2.0访问令牌，并使用它调用OpenID提供者的UserInfo端点来获取声明。因为OIDC是OAuth2.0之上的一层 ，应用程序可以使用OpenID提供程序进行用户身份验证和授权，以调用OpenID提供程序的API。通过这个示例，我们了解了OIDC的基本概念。下一节将定义一些附加术语，以便我们提供进一步的细节和更准确的描述。 +当用户访问应用程序时，它会将用户的浏览器重定向到实现OIDC的授权服务器。 OIDC将这样的授权服务器称为OpenID提供者\(OpenID Provider\)，我们将在本章中使用该术语。OpenID提供者与用户交互以验证他们的身份（假设他们还没有登录）。身份验证后，用户的浏览器将重定向回应用程序。应用程序可以请求在称为ID令牌的安全令牌中返回关于已验证用户的声明。或者，它可以请求Oauth2.0访问令牌，并使用它调用OpenID提供者的UserInfo端点来获取声明。因为OIDC是OAuth2.0之上的一层 ，应用程序可以使用OpenID提供程序进行用户身份验证和授权，以调用OpenID提供程序的API。通过这个示例，我们了解了OIDC的基本概念。下一节将定义一些附加术语，以便我们提供进一步的细节和更准确的描述。 ## 术语 我们将对以上提到的术语进行进一步准确的定义和解释： -* 最终用户End User – 最终用户是要验证的主体。 (我们将使用术语“用户”来简化和保持各章节的一致性。） - +* 最终用户End User – 最终用户是要验证的主体。 \(我们将使用术语“用户”来简化和保持各章节的一致性。） * OpenID提供者（OP） – OpenID提供程者是Oauth2.0授权服务器实现OIDC，并对用户进行身份验证，将有关已验证用户和身份验证事件的声明返回给依赖方（应用程序）。 * 依赖方（RP） – OAuth 2.0 将用户身份验证委托给OpenID提供者，并从OpenID提供程序请求有关用户的声明的客户端。对于依赖方，我们通常使用“应用”一词 来保持跨章节的一致性。 @@ -46,17 +44,13 @@ OIDC除了利用OAuth 2.0中描述的的授权和令牌端点以外，增加加U UserInfo Endpoint–返回关于经过身份验证的用户的声明。调用端点需要访问令牌，并且返回的声明由访问令牌控制。 - - ### ID Token ID Token令牌是OpenID提供者用来向应用程序传递关于身份验证事件和身份验证用户的声明的安全令牌。ID令牌以Json Web Token（JWT）[iii](https://tools.ietf.org/html/rfc7519)格式编码。图7-2显示了一个示例ID令牌。 - - ![7-2 OIDC IDToken.jpg](https://i.loli.net/2021/07/16/IraHYnfyRzp8qTl.jpg) -
7-2 ID Token
+7-2 ID Token JWT格式旨在在双方之间传递声明。作为JWT，ID令牌由报头（Header）、有效负载（Payload）和签名（Signature）组成。最终，这些组合在一起通过base-64进行编码。 @@ -69,11 +63,8 @@ JWT格式旨在在双方之间传递声明。作为JWT，ID令牌由报头（Hea 包含关于用户和身份验证事件的声明。主要包括： * 发行人 - * 主体或经过身份验证的用户（通常是资源所有者） - * 用户如何认证以及何时认证 - * 令牌的对象（即受众） 这些标记非常灵活，允许您添加自己的声明 @@ -86,24 +77,22 @@ JWT格式旨在在双方之间传递声明。作为JWT，ID令牌由报头（Hea OIDC规范中，ID令牌JWT的Payload定义了一组适用于所有类型的OIDC身份验证的用户和身份验证事件的声明[vi](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)。如表7-1所示。 -| Claims 声明 | 含义 | -| ----------- | ------------------------------------------------------------ | -| iss | ID令牌的颁发者，以URL格式标识。颁发者通常是OpenID提供者。“iss”声明不应包括URL查询或片段组件。 | -| sub | 唯一的（在OpenID提供者中），对已验证用户或主题实体区分大小写的字符串标识符，长度不超过255个ASCII字符。决不应将子声明中的标识符重新分配给新用户或实体。 | -| aud | ID令牌所针对的依赖方（应用程序）的客户端ID。单个区分大小写的字符串，如果有多个访问群体，则可以是区分大小写的字符串的数组。 | -| jti | Jti声明为JWT提供了唯一的标识符。 实现JTI以唯一地标识JWT可以帮助防止攻击者发送相同JWT以发出请求的重放攻击.服务器将生成jti值,并在每个响应上将其与新的JWT一起发送.当收到新请求时,服务器必须验证jti值(以确保它之前没有使用过). | -| iat | 颁发ID令牌的时间，指定为自1970年1月1日00:00:00 UTC到ID令牌颁发时间的秒数。 | -| exp | ID令牌的过期时间，指定为自1970年1月1日00:00:00 UTC到令牌过期时间的秒数。应用程序必须在这个时间之后考虑ID令牌无效，允许对时钟偏移允许几分钟的公差。 | -| idp | 颁发令牌的IDP的唯一标识 | -| auth_time | 用户通过身份验证的时间，指定为自1970年1月1日00:00:00 UTC到身份验证时间的秒数。 | -| nonce | 从依赖方传入的身份验证请求中传递的不可使用的、区分大小写的字符串值，由OpenID提供程序添加到ID令牌中，以将ID令牌链接到依赖方应用程序会话，并便于检测重播的ID令牌。 | -| amr | 【可选】身份验证方法引用的字符串–用于指示用于对ID令牌的主题实体进行身份验证的身份验证方法。认证方法参考值规范[vii](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-amr-values-04)为该声明定义了一组初始标准值。 | -| acr | 【可选】包含身份验证上下文类引用的字符串–用于指示用于对ID令牌的主题进行身份验证的身份验证机制的身份验证上下文类。值可以由OpenID提供者决定，也可以由依赖方和OpenID提供者商定，并且可以使用诸如OpenID Connect扩展身份验证配置文件ACR值草案之类的标准[viii](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html) | -| azp | 【可选】Authorized party，结合aud使用。只有在被认证的一方和受众（aud）不一致时才使用此值，一般情况下很少使用。 | - -ID令牌可以包含表7-1中所列之外的额外声明。可以添加的附加声明包含：username, given_name, family_name, email, email_verified, locale, and picture等等。附加标准声明的列表可以参考OIDC核心规范的第5.1节[ix](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)。特定类型的OIDC请求（流）可能涉及附加声明。也可以添加自定义的声明，如IDP等。 - - +| Claims 声明 | 含义 | +| :--- | :--- | +| iss | ID令牌的颁发者，以URL格式标识。颁发者通常是OpenID提供者。“iss”声明不应包括URL查询或片段组件。 | +| sub | 唯一的（在OpenID提供者中），对已验证用户或主题实体区分大小写的字符串标识符，长度不超过255个ASCII字符。决不应将子声明中的标识符重新分配给新用户或实体。 | +| aud | ID令牌所针对的依赖方（应用程序）的客户端ID。单个区分大小写的字符串，如果有多个访问群体，则可以是区分大小写的字符串的数组。 | +| jti | Jti声明为JWT提供了唯一的标识符。 实现JTI以唯一地标识JWT可以帮助防止攻击者发送相同JWT以发出请求的重放攻击.服务器将生成jti值,并在每个响应上将其与新的JWT一起发送.当收到新请求时,服务器必须验证jti值\(以确保它之前没有使用过\). | +| iat | 颁发ID令牌的时间，指定为自1970年1月1日00:00:00 UTC到ID令牌颁发时间的秒数。 | +| exp | ID令牌的过期时间，指定为自1970年1月1日00:00:00 UTC到令牌过期时间的秒数。应用程序必须在这个时间之后考虑ID令牌无效，允许对时钟偏移允许几分钟的公差。 | +| idp | 颁发令牌的IDP的唯一标识 | +| auth\_time | 用户通过身份验证的时间，指定为自1970年1月1日00:00:00 UTC到身份验证时间的秒数。 | +| nonce | 从依赖方传入的身份验证请求中传递的不可使用的、区分大小写的字符串值，由OpenID提供程序添加到ID令牌中，以将ID令牌链接到依赖方应用程序会话，并便于检测重播的ID令牌。 | +| amr | 【可选】身份验证方法引用的字符串–用于指示用于对ID令牌的主题实体进行身份验证的身份验证方法。认证方法参考值规范[vii](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-amr-values-04)为该声明定义了一组初始标准值。 | +| acr | 【可选】包含身份验证上下文类引用的字符串–用于指示用于对ID令牌的主题进行身份验证的身份验证机制的身份验证上下文类。值可以由OpenID提供者决定，也可以由依赖方和OpenID提供者商定，并且可以使用诸如OpenID Connect扩展身份验证配置文件ACR值草案之类的标准[viii](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html) | +| azp | 【可选】Authorized party，结合aud使用。只有在被认证的一方和受众（aud）不一致时才使用此值，一般情况下很少使用。 | + +ID令牌可以包含表7-1中所列之外的额外声明。可以添加的附加声明包含：username, given\_name, family\_name, email, email\_verified, locale, and picture等等。附加标准声明的列表可以参考OIDC核心规范的第5.1节[ix](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)。特定类型的OIDC请求（流）可能涉及附加声明。也可以添加自定义的声明，如IDP等。 ## OIDC如何工作 @@ -121,9 +110,7 @@ OIDC授权代码流类似于OAuth2.0授权代码授，整个流程中，主要 ![7-3 OIDC CodeFlow.jpg](https://i.loli.net/2021/07/16/jSY3WfZekLt4GO7.jpg) -
OIDC 授权码流程
- - +OIDC 授权码流程 1. 用户向应用（RP）发起请求 2. 应用向OpenID 提供者发出一个请求，发送一个基本的授权范围，该请求通过浏览器进行重定向。 @@ -142,7 +129,7 @@ OIDC授权代码流类似于OAuth2.0授权代码授，整个流程中，主要 应用程序通过浏览器将用户的身份验证请求重定向到OpenID提供程序的授权端点，例如 -``` +```text GET /authorize? response_type=code @@ -162,21 +149,21 @@ response_type=code 该示例中使用的参数如表7-2所示，但不同的OpenID提供者会有所差异。 -| 参数 | 说明 | -| --------------------- | ------------------------------------------------------------ | -| response_type | 指示OIDC授权类型。“code”用于指示该流程为授权码流程。 | -| client_id | 应用程序的标识符，在向OpenID服务器注册时分配。 | -| response_mode | 一个可选参数，请求授权服务器用于向客户端应用程序传递响应参数为非默认方式时，可以指定该参数 | -| state | 一个不可猜测的字符串，对于每个调用都是唯一的，对授权服务器来说是不透明的，客户端使用它来跟踪相应请求和响应之间的状态，以降低CSRF攻击的风险。它应该包含一个将请求与用户会话相关联的值。这可以通过将会话cookie或其他会话标识符的散列与附加的每个请求唯一组件连接起来来实现。当收到响应时，客户机应确保响应中的状态参数与从同一浏览器发送的请求的状态参数匹配。 | -| scope | 本次请求授予权限的范围。例如：openid，profile，email | -| nonce | 在请求中传递给OpenID提供者的不可猜测的值，如果请求了ID令牌，则在ID令牌中返回该值未修改的声明。用于防止令牌重放。 | -| redirect_uri | 指示应用程序的回调URL，OpenID提供者将其带有授权代码的响应发送到此URL。 | -| code_challenge | PKCE挑战码，由PKCE编码验证码派生 | -| code_challenge_method | PKCE中指示生成挑战码的派生方法。 “S256” or “plain.” | +| 参数 | 说明 | +| :--- | :--- | +| response\_type | 指示OIDC授权类型。“code”用于指示该流程为授权码流程。 | +| client\_id | 应用程序的标识符，在向OpenID服务器注册时分配。 | +| response\_mode | 一个可选参数，请求授权服务器用于向客户端应用程序传递响应参数为非默认方式时，可以指定该参数 | +| state | 一个不可猜测的字符串，对于每个调用都是唯一的，对授权服务器来说是不透明的，客户端使用它来跟踪相应请求和响应之间的状态，以降低CSRF攻击的风险。它应该包含一个将请求与用户会话相关联的值。这可以通过将会话cookie或其他会话标识符的散列与附加的每个请求唯一组件连接起来来实现。当收到响应时，客户机应确保响应中的状态参数与从同一浏览器发送的请求的状态参数匹配。 | +| scope | 本次请求授予权限的范围。例如：openid，profile，email | +| nonce | 在请求中传递给OpenID提供者的不可猜测的值，如果请求了ID令牌，则在ID令牌中返回该值未修改的声明。用于防止令牌重放。 | +| redirect\_uri | 指示应用程序的回调URL，OpenID提供者将其带有授权代码的响应发送到此URL。 | +| code\_challenge | PKCE挑战码，由PKCE编码验证码派生 | +| code\_challenge\_method | PKCE中指示生成挑战码的派生方法。 “S256” or “plain.” | -
7-2 OIDC 认证请求参数
+7-2 OIDC 认证请求参数 -身份验证请求中的response_type参数用于指示所需的OIDC流。可选参数response_mode控制将响应参数返回到应用程序的方法。除非另有说明，否则一般不指定response_mode，默认响应模式是使用查询参数或散列片段方式在重定向uri中将授权码、安全令牌等返回。 +身份验证请求中的response\_type参数用于指示所需的OIDC流。可选参数response\_mode控制将响应参数返回到应用程序的方法。除非另有说明，否则一般不指定response\_mode，默认响应模式是使用查询参数或散列片段方式在重定向uri中将授权码、安全令牌等返回。 OAuth2.0中的Scope参数用于请求通过访问令牌授予API特权。对于OIDC身份验证请求，作用域用于指示OIDC的使用，并请求有关已验证用户信息的特定声明。OIDC身份验证请求必须包含“openid”，“profile”用于包含请求默认的用户配置文件声明的授权，例如name、family name和given name。“email”用于请求用户的电子邮件地址以及该地址是否已被验证。如果是通过访问令牌去请求向OpenID提供者的UserInfo端点，这些作用域将会限制应用请求返回用户信息时的权限，只会返回被授予的作用域范围内的声明。如果未颁发访问令牌，则请求的声明将包含在ID令牌中。有关请求声明的更多详细信息，请参见OpenID Connect Core规范的第5.4节和第5.5节[x](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims)。 @@ -188,7 +175,7 @@ OAuth2.0中的Scope参数用于请求通过访问令牌授予API特权。对于O OpenID提供程序返回对身份验证请求中指定的重定向URI的响应，该URI必须在OpenID提供者处注册。对于授权码流，默认响应模式使用查询参数将授权码返回到身份验证请求中指定的重定向URI（回调），同时返回在身份验证请求中传递的状态值。 -``` +```text HTTP/1.1 302 Found Location: https://clientapplication.com/callback? @@ -204,7 +191,7 @@ code= 应用程序使用授权码向OpenID提供者的令牌端点请求令牌。下面的示例为非公共客户端使用其密钥，通过HTTP基本身份验证，向OpenID提供者的令牌端点请求令牌。 -``` +```text POST /token HTTP/1.1 Host: authorizationserver.com @@ -224,20 +211,18 @@ grant_type=authorization_code 应用程序使用授权码向OpenID提供者的令牌端点请求令牌时，需要进行客户端的认证，OIDC核心规范第9节[xii](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication)定义了身份验证方法的更多信息，具体方式可以参阅规范。令牌请求示例的参数如表7-3所示。 +| 参数 | 说明 | +| :--- | :--- | +| grant\_type | 指示授权类型,指定为“code”用于指示该流程为授权码流程。 | +| code | 授权响应中收到的授权码 | +| code\_verifier | 为了派生代码挑战码而产生的PKCE的验证码值。它应该是一个长度介于43到128个字符（含）之间的不可使用的加密随机字符串，使用字符A–Z、A–Z、0–9、“-”、“.”、“”和“~” | +| redirect\_uri | 授权服务器响应的回调URI。 应该与授权请求中传递给授权端点的重定向uri的值相匹配 | - -| 参数 | 说明 | -| ------------- | ------------------------------------------------------------ | -| grant_type | 指示授权类型,指定为“code”用于指示该流程为授权码流程。 | -| code | 授权响应中收到的授权码 | -| code_verifier | 为了派生代码挑战码而产生的PKCE的验证码值。它应该是一个长度介于43到128个字符（含）之间的不可使用的加密随机字符串，使用字符A–Z、A–Z、0–9、“-”、“.”、“”和“~” | -| redirect_uri | 授权服务器响应的回调URI。 应该与授权请求中传递给授权端点的重定向uri的值相匹配 | - -
7-3 令牌请求参数
+7-3 令牌请求参数 OpenID提供者将以JSON格式响应请求的令牌。下面是一个示例响应： -``` +```text HTTP/ 1.1 200 OK Content-Type: application/json;charset=UTF-8 @@ -263,42 +248,36 @@ Pragma: no-cache 响应包含的参数如表7-4所示 -| 参数 | 说明 | -| ------------- | ------------------------------------------------------------ | -| id_token | 包含用户信息声明的身份令牌 | -| access_token | 用于调用User Endpoint API的访问令牌。 | -| token_type | 颁发的令牌类型。 | -| expires_in | 令牌的有效期 | -| refresh_token | 刷新令牌 是可选的。 是否返回刷新令牌由授权服务器自行决定。有关更多信息，请参阅本章后面的刷新令牌部分。 | +| 参数 | 说明 | +| :--- | :--- | +| id\_token | 包含用户信息声明的身份令牌 | +| access\_token | 用于调用User Endpoint API的访问令牌。 | +| token\_type | 颁发的令牌类型。 | +| expires\_in | 令牌的有效期 | +| refresh\_token | 刷新令牌 是可选的。 是否返回刷新令牌由授权服务器自行决定。有关更多信息，请参阅本章后面的刷新令牌部分。 | -
7-4 令牌响应参数
+7-4 令牌响应参数 在信任ID令牌中的声明之前，应用程序应按照发布OpenID提供者提供的指导，JWT规范[xiii](https://datatracker.ietf.org/doc/html/rfc7519#section-7.2)中的验证步骤验证ID令牌。应用程序可以从ID令牌或通过使用访问令牌调用OpenID提供者的UserInfo端点来获取关于已验证用户的声明。 - - ### OIDC隐式模式 -OIDC中的隐式流程与OAuth2.0的隐式授权类型相似。 -如第6章所述，不建议使用OAuth2.0隐式授权来获取访问令牌，至少在默认响应模式下是这样。然而，该指导原则的前提是基于暴露URL片段中的访问令牌的风险，即该URL片段可能通过浏览器历史记录或referer头泄漏。如果，应用程序只需要对用户进行身份验证并且可以通过ID令牌获取用户信息，而不需要访问令牌。在这种情况下，隐式流是可以接受的。图7-4显示了应用程序仅接收ID令牌的流程。 +OIDC中的隐式流程与OAuth2.0的隐式授权类型相似。 如第6章所述，不建议使用OAuth2.0隐式授权来获取访问令牌，至少在默认响应模式下是这样。然而，该指导原则的前提是基于暴露URL片段中的访问令牌的风险，即该URL片段可能通过浏览器历史记录或referer头泄漏。如果，应用程序只需要对用户进行身份验证并且可以通过ID令牌获取用户信息，而不需要访问令牌。在这种情况下，隐式流是可以接受的。图7-4显示了应用程序仅接收ID令牌的流程。 ![7-4 OIDC implicit.jpg](https://i.loli.net/2021/07/16/ZDIVfbOosuFrktc.jpg) -
7-4 OIDC 隐式流程
+7-4 OIDC 隐式流程 1. 用户向应用（RP）发起请求 - 2. 应用向OpenID提供者发出一个请求，发送一个基本的授权范围，该请求通过浏览器进行重定向。 - 3. OpenID提供者器接下来将向用户发起身份验证，和征求用户的授权同意范围。 - 4. 用户通过输入凭据进行身份验证，并且对请求的权限进行授权，该授权将影响令牌中包含影响作用域的信息。 5. OpenID提供者生成本次授权请求的身份令牌（IDToken），然后将此令牌包含在重定向请求中，通过浏览器将令牌返回给应用。 6. 应用程序从ID令牌获取关于用户身份的声明，并向用户显示需要展示的内容。 使用隐式流程对用户进行身份验证的（仅请求ID令牌）身份验证请求，如下： -``` +```text GET /authorize? response_type=id_token @@ -313,29 +292,27 @@ response_type=id_token & redirect_uri= HTTP/1.1 -Host: authorizationserver.com - - +Host: authorizationserver.com ``` 隐式流身份验证请求中使用的参数，除了响应类型值意外，其他参数与表7-2所示相同的定义。对于隐式流，允许的响应类型值为： -* id_token--响应仅包含idtoken -* id_token token--响应包含id token和access token +* id\_token--响应仅包含idtoken +* id\_token token--响应包含id token和access token 默认情况下，隐式流使用URL片段通过前端浏览器交互将所有令牌返回到重定向URI。 > 注意 -不建议在默认响应模式下使用“id_token token”的response_type，因为它会通过referer头或浏览器的历史记录使访问令牌置于暴露于潜在的风险。如果ID令牌不包含敏感数据，则使用默认响应模式和“id_token”则无此风险。 +不建议在默认响应模式下使用“id\_token token”的response\_type，因为它会通过referer头或浏览器的历史记录使访问令牌置于暴露于潜在的风险。如果ID令牌不包含敏感数据，则使用默认响应模式和“id\_token”则无此风险。 -对于只需要ID令牌的应用程序，应考虑使用非默认de form_post响应模式，因为响应参数编码在post响应的主体中,这避免了通过一个URL片段公开ID令牌和数据，但是这种响应模式对于某些应用可能是不可行的。需要敏感的访问令牌和或ID令牌的公共客户端应该考虑使用PKCE授权码流来代替。 +对于只需要ID令牌的应用程序，应考虑使用非默认de form\_post响应模式，因为响应参数编码在post响应的主体中,这避免了通过一个URL片段公开ID令牌和数据，但是这种响应模式对于某些应用可能是不可行的。需要敏感的访问令牌和或ID令牌的公共客户端应该考虑使用PKCE授权码流来代替。 #### 响应 -下面显示对隐式流程身份验证请求的示例响应，该请求使用“id_token”响应类型，仅请求id令牌。 +下面显示对隐式流程身份验证请求的示例响应，该请求使用“id\_token”响应类型，仅请求id令牌。 -``` +```text HTTP/1.1 302 Found Location: https://clientapplication.com/callback# @@ -345,53 +322,42 @@ id_token= & state = ``` - - ### OIDC 混合流程 OIDC混合流包含授权代码流和隐式流程的元素。它是为既有安全后端，又有在前端执行JavaScript的客户端的应用程序而设计的。混合流支持诸如在对应用程序前端的前通道响应中返回ID令牌和授权码、让应用程序后端使用授权码从令牌端点获取访问令牌（和可选的刷新令牌）之类的模型。该流程如图7-5所示。 ![7-5-HybridFlow.jpg](https://i.loli.net/2021/07/16/IqRwzpSukUD3hsT.jpg) -
7-5 OIDC 混合流程
- - +7-5 OIDC 混合流程 1. 用户向应用（RP）发起请求 - 2. 应用向OpenID提供者发出一个请求，发送一个基本的授权范围，该请求通过浏览器进行重定向。 - 3. OpenID提供者接下来将向用户发起身份验证，和征求用户的授权同意。 - 4. 用户通过输入凭据进行身份验证，并且对请求的权限进行授权，该授权将影响令牌中包含影响作用域的信息。 5. OpenID提供者生成本次授权请求的授权码和IDToken，然后将此授权码和IDToken包含在重定向请求中，通过浏览器将授权码和ID Token返回给应用。 6. 客户端验证ID Token，如果合法，应用后端使用授权码向OpenID提供者的令牌端点发送获取令牌请求，以获取访问令牌。 7. 授权服务器向该应用颁发授权令牌（AccessToken），刷新令牌（可选）。 8. 应用使用此令牌来访问用户信息。 - - 身份验证请求的参数如表7-2所示，但混合流的响应类型使用三个不同的值来控制从OpenID提供者的授权端点返回响应中的令牌。可以通过对令牌端点的后续令牌请求来请求其他令牌。表7-5总结了响应类型的可能值。 -| response_type | 响应包含的类型 | -| ------------------- | ------------------------------------------------------------ | -| code id_token | 返回code，id_token | -| code token | 返回code，访问令牌 access token——不建议使用默认的response_mode | -| code id_token token | 返回code，身份令牌 ID Token，访问令牌 access token——不建议使用默认的response_mode | +| response\_type | 响应包含的类型 | +| :--- | :--- | +| code id\_token | 返回code，id\_token | +| code token | 返回code，访问令牌 access token——不建议使用默认的response\_mode | +| code id\_token token | 返回code，身份令牌 ID Token，访问令牌 access token——不建议使用默认的response\_mode | > 注意 不建议在默认响应模式下使用通过授权端点的前端通道响应返回访问令牌的响应类型，即“code token”和“code id token token”，因为访问令牌将在浏览器中作为URL片段公开，并且可能通过referer标头或浏览器历史中泄漏。 -如果使用默认响应模式，则应使用“code id_token”响应类型，仅使用前通道响应将id令牌和授权码返回到浏览器。然后，通过应用程序后端的安全通道交互，可以从OpenID提供者的令牌端点获得访问令牌和可选刷新令牌。 +如果使用默认响应模式，则应使用“code id\_token”响应类型，仅使用前通道响应将id令牌和授权码返回到浏览器。然后，通过应用程序后端的安全通道交互，可以从OpenID提供者的令牌端点获得访问令牌和可选刷新令牌。 在实际应用中，混合流的应用并不广泛。使用此流需要一个实现，该实现将同时提供前端和后端信息，例如nonce和state，用这些信息验证它们接收到的任何响应和安全令牌，并防止诸如CSRF或令牌注入之类的攻击。应用程序应该考虑使用具有PKCE的授权代码流，除非它们具有需要混合流的特定用例。 +下面的示例中显示了使用混合流和“code id\_token”响应类型和默认响应模式的示例身份验证请求，参数定义与前面的示例类似。 - -下面的示例中显示了使用混合流和“code id_token”响应类型和默认响应模式的示例身份验证请求，参数定义与前面的示例类似。 - -``` +```text GET /authorize? response_type=code%20id_token @@ -406,8 +372,7 @@ response_type=code%20id_token &nonce= HTTP/1.1 -Host: authorizationserver.com - +Host: authorizationserver.com ``` 当应用程序接收到响应时，应用程序后端可以使用授权码去请求更多的令牌，如前一节中对授权码流所述。 @@ -418,19 +383,17 @@ Host: authorizationserver.com 对UserInfo端点的示例应用程序请求如下所示： -``` +```text GET /userinfo HTTP/1.1 Host: authorizationserver.com Authorization: Bearer - - ``` OpenID提供者的UserInfo端点响应返回带有JSON对象的声明（除非使用签名或加密的响应）。下面的示例是请求范围为“openid profile email”响应。 -``` +```text HTTP/1.1 200 OK Content-Type: application/json @@ -454,12 +417,8 @@ Content-Type: application/json "picture":"https://oneauth.com/profile/yang.yu/yang.yu.jpg", } - - ``` - - 如果所需的用户配置文件声明对于通过URL片段返回的ID令牌来说太大，则使用UserInfo端点来返回用户的信息。 ## 本章重点回顾 @@ -473,29 +432,29 @@ OIDC允许应用程序将用户身份验证委托给OpenID提供者，同时使 ## 参考： -i: https://openid.net/connect/ +i: [https://openid.net/connect/](https://openid.net/connect/) -ii:https://datatracker.ietf.org/doc/html/rfc8252 +ii:[https://datatracker.ietf.org/doc/html/rfc8252](https://datatracker.ietf.org/doc/html/rfc8252) -iii:https://tools.ietf.org/html/rfc7519 +iii:[https://tools.ietf.org/html/rfc7519](https://tools.ietf.org/html/rfc7519) -iv:https://datatracker.ietf.org/doc/html/rfc7515 +iv:[https://datatracker.ietf.org/doc/html/rfc7515](https://datatracker.ietf.org/doc/html/rfc7515) -v:https://datatracker.ietf.org/doc/html/rfc7516 +v:[https://datatracker.ietf.org/doc/html/rfc7516](https://datatracker.ietf.org/doc/html/rfc7516) -vi:https://openid.net/specs/openid-connect-core-1_0.html#IDToken +vi:[https://openid.net/specs/openid-connect-core-1\_0.html\#IDToken](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) -vii:https://datatracker.ietf.org/doc/html/draft-ietf-oauth-amr-values-04 +vii:[https://datatracker.ietf.org/doc/html/draft-ietf-oauth-amr-values-04](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-amr-values-04) -viii:https://openid.net/specs/openid-connect-eap-acr-values-1_0.html +viii:[https://openid.net/specs/openid-connect-eap-acr-values-1\_0.html](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html) -ix：https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims +ix：[https://openid.net/specs/openid-connect-core-1\_0.html\#StandardClaims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) -x：https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims +x：[https://openid.net/specs/openid-connect-core-1\_0.html\#ScopeClaims](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) -xi:https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest +xi:[https://openid.net/specs/openid-connect-core-1\_0.html\#AuthRequest](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) -xii:https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication +xii:[https://openid.net/specs/openid-connect-core-1\_0.html\#ClientAuthentication](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) -xiii：https://datatracker.ietf.org/doc/html/rfc7519#section-7.2 +xiii：[https://datatracker.ietf.org/doc/html/rfc7519\#section-7.2](https://datatracker.ietf.org/doc/html/rfc7519#section-7.2) diff --git a/docs/modernidentity/ChapterSix.md b/xie-yi/chaptersix.md similarity index 80% rename from docs/modernidentity/ChapterSix.md rename to xie-yi/chaptersix.md index f6b2d3b..8e8cad8 100644 --- a/docs/modernidentity/ChapterSix.md +++ b/xie-yi/chaptersix.md @@ -1,4 +1,4 @@ -# 深入学习OAuth2.0 +# 第六章 深入学习OAuth2.0 为了解决在API中进行身份管理的需要，您必须建立在坚实的基础上。你需要在协议和标准上建立你的API安全基础设施，并且这些标准是已经通过同行评审，并被市场采用。长期以来，缺乏这样的标准这一直是大型组织希望采用RestfulAPI的主要障碍。 @@ -16,15 +16,13 @@ OAuth 2与OIDC的诞生，解决了这一问题，他是保护API的基础。OAu 接下来，我们通过例子来详细了解OAuth的原理。 - - ## API访问授权 应用程序可能需要代表用户调用API，以访问用户拥有的内容，或者应用程序自身拥有所需的内容，则需要代表自己调用API。通过下图 6-1示例的场景说明这两种情况。 ![6-1 API AuthZ.jpg](https://i.loli.net/2021/07/16/xK9MLrFPnvwWQh8.jpg) -
6-1授权示例
+ 6-1授权示例 在这个场景中，写作应用程序是一个专门的编辑器，帮助用户撰写和编辑文章。它调用两个API，它们都属于不同的组织。第一个是素材库，它为文章提供有效的素材。第二个是文档服务，提供文档存储服务。还有第一个移动应用程序，它调用文档服务来提供从用户的移动设备访问文档的权限。 @@ -52,19 +50,17 @@ OAuth 2与OIDC的诞生，解决了这一问题，他是保护API的基础。OAu ![6-2 OAuth Actors.jpg](https://i.loli.net/2021/07/16/pUbtDSglOx5zyNq.jpg) -
6-2 OAuth 角色
- - +6-2 OAuth 角色 ### 公共与非公开的客户端 OAuth2.0定义了两种客户端类型： * 公共客户端 – 一种主要在用户侧设备上运营的程序，如（手机APP应用程序）或客户端浏览器中执行的应用程序，它不能安全地存储秘密。 - * 非公开客户端 – 在受保护的服务器上运行的一种应用程序，它可以安全地存储机密，可以一种安全的机制向授权服务器进行身份验证，并存储授权服务器返回的机密。 ### 客户端类型 + OAuth 2.0基于应用程序拓扑定义了三个概要的类型： * Web应用程序 – 在受保护的后端服务器上执行代码的机密客户端。服务器可以安全地存储客户端进行身份验证所需的任何机密以及从授权服务器接收的任何令牌。 @@ -78,9 +74,7 @@ OAuth 2.0基于应用程序拓扑定义了三个概要的类型： 在OAuth中，定义了两种令牌和一个授权码，换句话说，就是具有不同用途的令牌和授权码： * 授权码 – 返回给应用程序的一种中间的不透明一次性代码，用于获取访问令牌和可选的刷新令牌。每个授权码使用一次。 - * 访问令牌：应用程序用来访问API的令牌。 它表示应用程序调用API的授权，并且有一个过期时间 - * 刷新令牌：一种可选令牌，当先前的访问令牌过期时，应用程序可以使用它来请求新的访问令牌。 把访问令牌想象成一个会话，它是在您登录到网站时为您创建的。只要该会话有效，您就可以继续与网站进行交互，而无需再次登录。一旦该会话过期，您可以通过密码再次登录来获取新会话。在这种类比中，刷新令牌有点类似于密码。还有，客户端需要确保刷新令牌的安全。它应该以一种安全的方式进行凭据存储。 @@ -112,18 +106,13 @@ OAuth 2.0 授权框架规范定义了四种方法，应用程序通过这些方 第二次请求发生在应用获取到授权码后，应用向授权服务器的令牌端点发送获取令牌请求，在此请求中，包含了授权码和授权码验证信息，以获取访问令牌。授权服务器向该应用颁发授权令牌（AccessToken），返回访问令牌进行响应 ，应用就可以用此令牌来调用资源服务的API。图 6-3显示了步骤的顺序。 - - ![6-3 OAuth Process.jpg](https://i.loli.net/2021/07/16/Bs6kSKYQmJhlg1c.jpg) -
6-3 OAuth Code Flow
+6-3 OAuth Code Flow 1. 用户向应用发起请求 - 2. 应用向OAuth服务器发出一个请求，发送一个基本的授权范围，该请求通过浏览器进行重定向。 - 3. OAuth授权服务器接下来将向用户发起身份验证，和征求用户的授权同意。 - 4. 用户通过输入凭据进行身份验证，并且对请求的权限进行授权，该授权将影响令牌中包含影响作用域的信息。 5. 授权服务器生成本次授权请求的授权码，然后将此授权码包含在重定向请求中，通过浏览器将授权码返回给应用。 6. 应用向授权服务器的令牌端点发送获取令牌请求，在此请求中，包含了授权码，以获取访问令牌。 @@ -134,8 +123,7 @@ OAuth 2.0 授权框架规范定义了四种方法，应用程序通过这些方 第一个（授权）请求将用户重定向到授权服务器，以便授权服务器可以与用户交互。 -第二个（授权）请求可以由应用程序的后端直接向授权服务器的令牌端点发出。这是假定非公开的客户端（应用后段）能够安全地管理认证秘密，因而应用程序后端可以向授权服务器提供秘密并进行自身认证，并自认证成功后获取访问令牌。这还意味着可以将带有访问令牌的响应传递到应用程序后端，这将使应用可以在后续进行 API调用。这种设计的另外一个优点是令牌可以通过安全的反向通道响应返回。 -不过， 虽然这种方式开始只针对非公开的客户端进行了优化，但通过添加PKCE的方式，使得公共客户端也可以使用这种授权码流程。 +第二个（授权）请求可以由应用程序的后端直接向授权服务器的令牌端点发出。这是假定非公开的客户端（应用后段）能够安全地管理认证秘密，因而应用程序后端可以向授权服务器提供秘密并进行自身认证，并自认证成功后获取访问令牌。这还意味着可以将带有访问令牌的响应传递到应用程序后端，这将使应用可以在后续进行 API调用。这种设计的另外一个优点是令牌可以通过安全的反向通道响应返回。 不过， 虽然这种方式开始只针对非公开的客户端进行了优化，但通过添加PKCE的方式，使得公共客户端也可以使用这种授权码流程。 #### 授权码 Authorization Code+PKCE @@ -145,15 +133,13 @@ OAuth 2.0 授权框架规范定义了四种方法，应用程序通过这些方 当该流程进行到步骤6时，应用向授权服务器的令牌端点请求获取访问令牌时，需要在请求中将授权码以及编码验证码同时发送到授权服务器。授权服务器使用在授权请求中接收的转换方法对编码验证码进行转换，与第二步随授权请求发送的编码挑战码进行质询匹配。这使授权服务器能够辨别是否时恶意应用程序在试图使用被盗的授权代码。只有合法的应用程序才知道代码验证器要第6步中将需要传递的编码验证码。 - - PKCE规范列出了可用于从编码验证码派生代码挑战码的两种转换方法，即“plain”和“S256”。使用“plain”方法，代码挑战码和验证码是相同的，因此没有针对有可能被窃取的代码挑战码的保护。使用PKCE授权码的应用程序应该使用S256转换方法，该方法使用代码验证器的base64url编码的SHA256散列来保护它。 #### 授权请求 下面是一个应用基于PKCE模式向授权服务请求API授权的示例。 它将被定向到授权服务器的授权端点。 -``` +```text GET /authorize？ response_type=code & client_id= @@ -163,31 +149,29 @@ response_type=code & resource= & code_challenge= & code_challenge_method=S256 HTTP/1.1 -Host: authorizationserver.com` +Host: authorizationserver.com` ``` -**表 6-1.** *授权请求的参数说明* +**表 6-1.** _授权请求的参数说明_ -| 参数 | 说明 | -| --------------------- | ------------------------------------------------------------ | -| response_type | 指示OAuth 2.0授权类型。“code”用于指示该流程为授权码流程。 | -| client_id | 应用程序的标识符，在向授权服务器注册时分配。 | -| state | 一个不可猜测的字符串，对于每个调用都是唯一的，对授权服务器来说是不透明的，客户端使用它来跟踪相应请求和响应之间的状态，以降低CSRF攻击的风险。它应该包含一个将请求与用户会话相关联的值。这可以通过将会话cookie或其他会话标识符的散列与附加的每个请求唯一组件连接起来来实现。当收到响应时，客户机应确保响应中的状态参数与从同一浏览器发送的请求的状态参数匹配。 | -| scope | 本次请求授予权限的范围。例如：“read:documents” | -| redirect_uri | 指示应用程序的回调URL，授权服务器将其带有授权代码的响应发送到此URL。 | -| resource | 在请求访问令牌的授权服务器上注册的特定API的标识符。此参数在中定义 oauth2.0扩展当中，资源指示符有些实现可能会使用其他名称，例如“audience.”，主要用于具有自定义api的部署中。如果具有多个API服务，用于区分，否则不需要此参数。 | -| code_challenge | PKCE挑战码，由PKCE编码验证码派生 | -| code_challenge_method | PKCE中指示生成挑战码的派生方法。 “S256” or “plain.” | +| 参数 | 说明 | +| :--- | :--- | +| response\_type | 指示OAuth 2.0授权类型。“code”用于指示该流程为授权码流程。 | +| client\_id | 应用程序的标识符，在向授权服务器注册时分配。 | +| state | 一个不可猜测的字符串，对于每个调用都是唯一的，对授权服务器来说是不透明的，客户端使用它来跟踪相应请求和响应之间的状态，以降低CSRF攻击的风险。它应该包含一个将请求与用户会话相关联的值。这可以通过将会话cookie或其他会话标识符的散列与附加的每个请求唯一组件连接起来来实现。当收到响应时，客户机应确保响应中的状态参数与从同一浏览器发送的请求的状态参数匹配。 | +| scope | 本次请求授予权限的范围。例如：“read:documents” | +| redirect\_uri | 指示应用程序的回调URL，授权服务器将其带有授权代码的响应发送到此URL。 | +| resource | 在请求访问令牌的授权服务器上注册的特定API的标识符。此参数在中定义 oauth2.0扩展当中，资源指示符有些实现可能会使用其他名称，例如“audience.”，主要用于具有自定义api的部署中。如果具有多个API服务，用于区分，否则不需要此参数。 | +| code\_challenge | PKCE挑战码，由PKCE编码验证码派生 | +| code\_challenge\_method | PKCE中指示生成挑战码的派生方法。 “S256” or “plain.” | 注：“resource”参数不在原始OAuth2.0规范中，刚开始，授权服务器被编写来处理多个API的请求。后来为了可以支持特定API的请求，额外的参数用来指示授权请求的特定API，该参数可以称为“resource”或“audience”。 - #### 授权响应 -授权服务器向应用程序的回调地址发送如下响应，回调地址在授权请求的redirect_uri参数中指定。 - +授权服务器向应用程序的回调地址发送如下响应，回调地址在授权请求的redirect\_uri参数中指定。 -``` +```text HTTP/1.1 302 Found Location: https://clientapplication.com/callback? @@ -197,18 +181,18 @@ code= & state= ``` -**表 6-2.** *授权响应的参数说明* +**表 6-2.** _授权响应的参数说明_ -| 参数 | 说明 | -| ----- | ------------------------------------------------------------ | -| code | 应用程序用于请求访问令牌的授权码。 | +| 参数 | 说明 | +| :--- | :--- | +| code | 应用程序用于请求访问令牌的授权码。 | | state | 在授权请求中发送的未修改的state值。应用程序必须验证响应中的状态值是否与初始请求发送的状态值匹配。 | #### 请求Token令牌 在接收到授权码之后，应用程序在对授权服务器的令牌端点发起的第二次请求中使用授权码来获取访问令牌。 -``` +```text POST /token HTTP/1.1 Host: authorizationserver.com @@ -226,19 +210,19 @@ grant_type=authorization_code & redirect_uri=<*callback URI*> ``` -**表 6-3.** *请求授权令牌中的参数说明* +**表 6-3.** _请求授权令牌中的参数说明_ -| 参数 | 说明 | -| ------------- | ------------------------------------------------------------ | -| grant_type | 指示OAuth 2.0授权类型,指定为“code”用于指示该流程为授权码流程。 | -| code | 授权响应中收到的授权码 | -| client_id | 应用程序的标识符，在向授权服务器注册时分配。 | -| code_verifier | 为了派生代码挑战码而产生的PKCE的验证码值。它应该是一个长度介于43到128个字符（含）之间的不可使用的加密随机字符串，使用字符A–Z、A–Z、0–9、“-”、“.”、“”和“~” | -| redirect_uri | 授权服务器响应的回调URI。 应该与授权请求中传递给授权端点的重定向uri的值相匹配 | +| 参数 | 说明 | +| :--- | :--- | +| grant\_type | 指示OAuth 2.0授权类型,指定为“code”用于指示该流程为授权码流程。 | +| code | 授权响应中收到的授权码 | +| client\_id | 应用程序的标识符，在向授权服务器注册时分配。 | +| code\_verifier | 为了派生代码挑战码而产生的PKCE的验证码值。它应该是一个长度介于43到128个字符（含）之间的不可使用的加密随机字符串，使用字符A–Z、A–Z、0–9、“-”、“.”、“”和“~” | +| redirect\_uri | 授权服务器响应的回调URI。 应该与授权请求中传递给授权端点的重定向uri的值相匹配 | 来自令牌终结点的响应将示例以下内容类似： -``` +```text HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 @@ -258,51 +242,43 @@ Pragma: no-cache "refresh_token":"<*refresh_token*>" } - ``` - - 响应参数如表 6-4所示。 -**表 6-4.** *令牌响应中的参数说明* +**表 6-4.** _令牌响应中的参数说明_ -| 参数 | 说明 | -| ------------- | ------------------------------------------------------------ | -| access_token | 用于调用API的访问令牌。 不同的授权服务器可能对访问令牌使用不同的格式。 | -| token_type | 颁发的令牌类型。 | -| expires_in | 令牌的有效期 | -| refresh_token | 刷新令牌 是可选的。 是否返回刷新令牌由授权服务器自行决定。有关更多信息，请参阅本章后面的刷新令牌部分。 | +| 参数 | 说明 | +| :--- | :--- | +| access\_token | 用于调用API的访问令牌。 不同的授权服务器可能对访问令牌使用不同的格式。 | +| token\_type | 颁发的令牌类型。 | +| expires\_in | 令牌的有效期 | +| refresh\_token | 刷新令牌 是可选的。 是否返回刷新令牌由授权服务器自行决定。有关更多信息，请参阅本章后面的刷新令牌部分。 | -### 隐式授权 Implicit Grant +### 隐式授权 Implicit Grant OAuth2.0定义了一个隐式授权类型，该类型针对公共客户机（如单页应用程序）进行了优化。使用此授予类型可在一个请求中返回对应用程序的访问令牌。它是在浏览器中不广泛支持CORS（Cross-Origin Resource Sharing，跨源资源共享）标准的时候设计的，它们只能调用加载页面的域，这意味这类单页应用它们不能调用授权服务器的令牌端点。为了弥补这一限制，隐式授权类型让授权服务器通过使用URL散列片段在重定向中向应用程序返回令牌来响应授权请求。隐式授权类型的交互如图所示 6-4. ![6-4 OAuth Implict Process.jpg](https://i.loli.net/2021/07/16/mBcxHjECJzOhdG7.jpg) - - -
6-4 隐式授权流程
+6-4 隐式授权流程 1. 用户向应用发起请求 - 2. 应用向OAuth服务器发出一个请求，发送一个基本的授权范围，该请求通过浏览器进行重定向。 - 3. OAuth授权服务器接下来将向用户发起身份验证，和征求用户的授权同意。 - 4. 用户通过输入凭据进行身份验证，并且对请求的权限进行授权，该授权将影响令牌中包含影响作用域的信息。 5. 授权服务器生成本次授权请求的授权令牌（AccessToken），然后将此令牌包含在重定向请求中，通过浏览器将授权令牌（AccessToken）返回给应用。 6. 应用使用此令牌来调用资源服务的API。 自从OAuth2.0规范最初发布以来，CORS已经得到了大多数浏览器的支持。因此，最初为了这个目的而设计隐式授权类型就不再需要。此外，在URL散列片段中返回访问令牌会使访问令牌暴露于通过浏览器历史或referer头，存在的潜在泄漏风险。因此，对于需要访问令牌的单页应用程序，不再建议使用URL哈希片段中返回访问令牌的隐式授予类型，而应改用授权码（PKCE）授予类型。 -还应该注意的是，在原始Oauth2.0规范发布之后，Oauth2.0多响应类型编码实践（Multiple Response Type Encoding Practices s）规范为授权请求定义了一个新的“Response_mode”参数，使应用程序能够请求以新的方式返回授权服务器响应。随后的规范定义了新的响应机制——Form Post Response Mode，将响应参数编码为HTML表单，该表单通过HTTP-Post发送到应用程序。OAuth 2.0 Web消息响应模式有一个规范草案，它利用HTML5Web消息传递将授权响应返回给应用程序。具有替代隐式授权类型响应的模式，为应用程序提供了新的选项，可以缓解与默认响应模式相关的问题。 +还应该注意的是，在原始Oauth2.0规范发布之后，Oauth2.0多响应类型编码实践（Multiple Response Type Encoding Practices s）规范为授权请求定义了一个新的“Response\_mode”参数，使应用程序能够请求以新的方式返回授权服务器响应。随后的规范定义了新的响应机制——Form Post Response Mode，将响应参数编码为HTML表单，该表单通过HTTP-Post发送到应用程序。OAuth 2.0 Web消息响应模式有一个规范草案，它利用HTML5Web消息传递将授权响应返回给应用程序。具有替代隐式授权类型响应的模式，为应用程序提供了新的选项，可以缓解与默认响应模式相关的问题。 #### 授权请求 -隐式授权类型的授权请求示例如下所示，其参数与前面的授权类型类似，但响应类型为“token” ，用于指示使用隐式授予类型，以及响应模式设置response_mode=form_post模式： +隐式授权类型的授权请求示例如下所示，其参数与前面的授权类型类似，但响应类型为“token” ，用于指示使用隐式授予类型，以及响应模式设置response\_mode=form\_post模式： -``` +```text GET /authorize? response_type=token @@ -319,27 +295,23 @@ response_type=token & state=<*state*> HTTP/1.1 -Host: authorizationserver.com +Host: authorizationserver.com ``` -隐式授权类型，如果使用默认的响应模式。则成功授权请求响应将访问令牌、令牌类型、令牌过期和状态值通过referer头重定向回应用程序的重定向URI，URL片段中的和浏览器历史会暴露这些敏感的信息。 使用form_post 模式的请求响应，将使这些值以HTML形式编码的响应发布到重定向uri，避免URL片段暴露。 +隐式授权类型，如果使用默认的响应模式。则成功授权请求响应将访问令牌、令牌类型、令牌过期和状态值通过referer头重定向回应用程序的重定向URI，URL片段中的和浏览器历史会暴露这些敏感的信息。 使用form\_post 模式的请求响应，将使这些值以HTML形式编码的响应发布到重定向uri，避免URL片段暴露。 ### 资源所有者密码凭证模式 -资源所有者密码凭据授予类型支持这样的情况：应用程序被信任来处理最终用户凭据，并且不可能有其他授予类型。对于这种授予类型，应用程序直接收集用户的凭据，而不是将用户重定向到授权服务器。应用程序将收集的凭据传递给授权服务器进行验证，作为其获取访问令牌请求的一部分。 -不鼓励使用此授予类型，因为它会向应用程序公开用户的凭据。它被用于用于遗留的嵌入式登录用户迁移场景。在这两种场景下，应用程序中的漏洞都会损害凭据。此外，此授予类型不涉及用户同意步骤，因此应用程序可以使用用户的凭据请求其希望的任何访问，用户无法防止应用滥用其凭据。 -因此，这种授权类型主要推荐用于用户迁移的用例。如果需要使用不兼容的密码散列将用户从一个标识存储库迁移到另一个标识存储库，则新系统可以提示用户输入其凭据，使用资源所有者密码授权来根据旧系统对其进行验证，如果有效，从旧系统检索用户配置文件，并将其和凭据存储在新系统中。这可以避免在迁移身份信息时进行大规模强制密码重置的必要性。如果使用此授予类型，则客户端应在获得访问令牌后立即丢弃用户凭据，以减少凭据受损的可能性。 +资源所有者密码凭据授予类型支持这样的情况：应用程序被信任来处理最终用户凭据，并且不可能有其他授予类型。对于这种授予类型，应用程序直接收集用户的凭据，而不是将用户重定向到授权服务器。应用程序将收集的凭据传递给授权服务器进行验证，作为其获取访问令牌请求的一部分。 不鼓励使用此授予类型，因为它会向应用程序公开用户的凭据。它被用于用于遗留的嵌入式登录用户迁移场景。在这两种场景下，应用程序中的漏洞都会损害凭据。此外，此授予类型不涉及用户同意步骤，因此应用程序可以使用用户的凭据请求其希望的任何访问，用户无法防止应用滥用其凭据。 因此，这种授权类型主要推荐用于用户迁移的用例。如果需要使用不兼容的密码散列将用户从一个标识存储库迁移到另一个标识存储库，则新系统可以提示用户输入其凭据，使用资源所有者密码授权来根据旧系统对其进行验证，如果有效，从旧系统检索用户配置文件，并将其和凭据存储在新系统中。这可以避免在迁移身份信息时进行大规模强制密码重置的必要性。如果使用此授予类型，则客户端应在获得访问令牌后立即丢弃用户凭据，以减少凭据受损的可能性。 资源所有者密码授予的交互类型如图6-5所示： ![6-5 OAuth RO Credentials Grant.jpg](https://i.loli.net/2021/07/16/kCBi7gUfpvdasVu.jpg) -
6-5 资源所有者密码凭证
+6-5 资源所有者密码凭证 1. 用户向应用发起请求 - 2. 应用直接向用户发起身份验证。 - 3. 用户将输入凭据提供给应用。 4. 应用将用户凭据传递给授权服务器，并请求令牌。 5. 授权服务器向该应用颁发授权令牌（AccessToken），刷新令牌（可选）。 @@ -349,9 +321,9 @@ Host: authorizationserver.com #### 授权请求 -资源所有者密码授予类型的令牌请求示例如下所示， 参数与之前的请求类型相似，但授予类型使用“grant_type=password”的类型，以及包含从用户处收集的用户名和密码。应用程序通过获得的用户凭据作为应用程序的授权， 并用于从令牌端点请求访问令牌。 +资源所有者密码授予类型的令牌请求示例如下所示， 参数与之前的请求类型相似，但授予类型使用“grant\_type=password”的类型，以及包含从用户处收集的用户名和密码。应用程序通过获得的用户凭据作为应用程序的授权， 并用于从令牌端点请求访问令牌。 -``` +```text POST /token HTTP/1.1 Host: authorizationserver.com @@ -379,20 +351,19 @@ grant_type=password ![6-6 OAuth Crediential Grant.jpg](https://i.loli.net/2021/07/16/YvfaWQzOU9wDiy5.jpg) -
6-6 客户端凭据流程
+ 6-6 客户端凭据流程 1. 应用程序将包括应用程序凭据的授权请求发送到授权服务器。 - 2. 授权服务器验证凭据并使用访问令牌进行响应。 3. 应用程序使用此令牌来调用资源服务的API。 -此流不需要最终用户与授权服务器交互。应用只需要通过自己的凭据去获取授权，该凭据由应用程序向授权服务器注册时获得，包含客户机Client_ID和Client_Secret。应用使用该凭据从令牌端点请求访问令牌。 +此流不需要最终用户与授权服务器交互。应用只需要通过自己的凭据去获取授权，该凭据由应用程序向授权服务器注册时获得，包含客户机Client\_ID和Client\_Secret。应用使用该凭据从令牌端点请求访问令牌。 #### 授权请求 -下面是客户端凭据授予类型的示例令牌请求，其参数定义与之前授予类型的类似， 但grant_type设置为“client_credentials”。在本例中，应用程序使用在授权服务器上注册的客户端Cilent_ID和Secret进行身份验证。 +下面是客户端凭据授予类型的示例令牌请求，其参数定义与之前授予类型的类似， 但grant\_type设置为“client\_credentials”。在本例中，应用程序使用在授权服务器上注册的客户端Cilent\_ID和Secret进行身份验证。 -``` +```text POST /token HTTP/1.1 Host: authorizationserver.com @@ -414,7 +385,7 @@ grant_type=client_credentials 一旦应用程序接收到访问令牌，它就会调用资源服务器并传递访问令牌。虽然不同的API的调用会有差异，但典型的方法是使用HTTP“Authorization”请求头字段，在授权头中使用承载身份验证令牌类型，并使用访问令牌，如以下代码段所示： -``` +```text GET /api-endpoint HTTP/1.1 Host: api-server.com @@ -432,11 +403,11 @@ OAuth 2.0中访问令牌具有有效期，当访问令牌过期时，应用程 刷新令牌为传统Web应用程序和本机应用程序获取新的访问令牌提供了一种方便的方法。 这有助于使用持续时间较短的访问令牌，从而将访问令牌受损的风险降至最低。一旦访问令牌过期，就自动刷新它可能很有诱惑力，但是为了保持最小特权的原则，最好只在需要时刷新访问令牌，而不是总是将当前的访问令牌保留在手边。 同样，应用程序必须安全地存储刷新令牌，因为它是敏感凭据。 - OAuth2.0规范没有为应用程序提供请求刷新令牌的机制，这让授权服务器自行决定是否发布令牌。因此，刷新令牌的处理可能会因各个授权服务器而异。有些自动发出刷新令牌，有些则希望应用程序显式请求刷新令牌(下一章将介绍的OIDC规范包括一种机制，用于应用程序为一个特定的用例请求刷新令牌。）撤销访问令牌的能力不是OAuth2.0规范中的强制功能，因此一些授权服务器可能不支持它。您选择的授权服务器的文档应解释具体实现的详细信息。 +OAuth2.0规范没有为应用程序提供请求刷新令牌的机制，这让授权服务器自行决定是否发布令牌。因此，刷新令牌的处理可能会因各个授权服务器而异。有些自动发出刷新令牌，有些则希望应用程序显式请求刷新令牌\(下一章将介绍的OIDC规范包括一种机制，用于应用程序为一个特定的用例请求刷新令牌。）撤销访问令牌的能力不是OAuth2.0规范中的强制功能，因此一些授权服务器可能不支持它。您选择的授权服务器的文档应解释具体实现的详细信息。 下面的示例中显示了对授权服务器的令牌端点的示例调用，以请求新的访问令牌。客户端必须对请求进行身份验证。 -``` +```text POST /token HTTP/1.1 Host: authorizationserver.com @@ -468,9 +439,8 @@ OAuth2.0协议使应用程序能够获得代表用户或自己调用API的授权 * 作用域用于控制应用程序在调用API时的访问权限。 * PKCE的授权码模式可以用于传统的Web应用程序、公共应用程序以及本机应用程序的授权使用。 - -* 不建议使用OAuth2.0隐式授予类型获取具有默认响应模式的访问令牌，因为它会使访问令牌暴露于潜在的危害。需要使用form_post方式。 +* 不建议使用OAuth2.0隐式授予类型获取具有默认响应模式的访问令牌，因为它会使访问令牌暴露于潜在的危害。需要使用form\_post方式。 * OAuth2.0资源所有者密码授予类型最好仅限于旧式用户迁移情况，因为它向应用程序公开用户凭据。 * 客户端凭据授予类型用于应用程序拥有请求的资源的API调用。 - * 刷新令牌用于在旧的访问令牌过期时获取新的访问令牌。OAuth2.0威胁模型和安全注意事项文档提出了刷新令牌轮换的概念，以检测刷新令牌是否被盗。要求授权服务器在每次访问令牌续订请求时返回一个新的刷新令牌。 +