Books

README.md

@@ -1 +1,10 @@
-# - 一本关于如何做好身份管理的书 a new book
+---
+description: An awesome identity book talk about how to build a morden identity.
+---
+
+# 现代身份建设指南
+
+## 一本如何做好现代身份管理的书
+
+## 
+

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)
+

docs/modernidentity/ChapterFive.md → 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。
+