从2000年以后，在如何存储和使用身份信息以使用户能够访问应用程序及其提供的功能方面一直在不断发展。您将在本章中看到，没隔几年时间，都会有新的需求和挑战，当然也会有对应新的方案，每一点进步都解决了一些问题，但也带来了新的问题。我们将回顾身份演进的历史，一边进一步去了解过去用于管理身份信息和提供身份验证和授权的方法。特定的技术来突出的特定优点和缺点，这些优点和缺点可以帮助您评估项目的解决方案。这也进一步帮助我们了解为什么我们应该使用行业标准协议，而不是发明自己的解决方案。
身份管理的发展概要
理解身协议演进的历史，也帮助我们理解互联网发展的现状，以及告诉我们未来应对的方法和发展趋势。
了解过去用于管理身份数据、身份验证和授权的方法的优缺点是很有价值的。其中许多方法至今仍在使用。这不是每种方法或技术的详尽的全部列表，而是一个精简的突出的优缺点列表，以给大家一个不同协议的直观的初步的理解。在阅读每一个解决方案时，请注意每个解决方案旨在解决的问题以及每个解决方案的优点和缺点。了解每种解决方案的优缺点将有助于您评估备选方案，并更有效地提倡使用新的解决方案。
我们首先按照时间回顾下身份发展的历史。
第一阶段：石器时代，各个应用使用独立的身份体系、独立进行认证和存储身份，后来基于Cookie进行内部应用的单点登录。
第二阶段，企业内部的应用越来越多，身份管理成为企业头痛的问题。2003年为了解决企业应用的联合认证的问题，微软联合、IBM等传统互联网巨头发起了基于WS*系列标准之上构建的WS-Federation1.1版本，但这一协议因为过于重，除了得到微软的积极拥护以外，其他软件厂商响应屈指可数。因而，2005年，SAML2.0横空出式，因为其协议的相对WS-Fed更为简洁明了，更因为适逢SaaS应用的发展，得到了一种SaaS厂商的支持。这也就是为何大家看到国外的SaaS平台基本上都继承了使用SAML的这一优良传统。
第三阶段，随着互联网、移动互联网的相继爆发，OpenID和OAuth应运而生，并且得到广泛的应用。在2012年以前，互联网之前的应用之间的信息交互较少。一方面互联网爆发式增长，让资源相互调用的需求迅猛增长，这也促进了OAuth2.0的诞生，同时，因为OAuth2.0，也让互联网应用之间的交互更加的蓬勃。
第四阶段，因为技术的演进，对于API的需求越来越多，2014年基于OpenID和OAuth2.0，OIDC于2014年发布，谷歌、微软、PingIDentity纷纷转向这一新的协议。微服务、云原生这几年概念火热，可以预见OIDC的应用将会越来越广泛。
石器时代-独立存储身份
在石器时代的计算机应用程序中，每个应用程序通常实现自己的身份存储库、身份验证和授权。大型企业公司通常有核心业务应用程序，如财务和库存控制系统，也许还有一些生产力应用程序。每个应用程序通常都有自己的专用数据库或其他存储，其中存储了用户身份、凭据和用户配置文件数据，每个应用程序都会提示用户登录，然后根据自己的用户配置文件存储库验证用户的凭据信息。这意味着员工可能需要为每个应用程序记住不同的用户名和密码。这也意味着，如果用户配置文件中的某个元素发生了更改，则必须在多个应用程序中进行配置文件更改。当然，如果一家公司有许多应用程序，这种情况就不会可靠地发生，因此用户配置文件数据在各个系统中总是不同步。当只有几个应用程序时，用户对数据完整性问题的恼怒和必须记住大量密码就足够糟糕了。然而，随着企业中应用程序数量的增长，让每个应用程序实现自己的筒仓式身份存储库和身份验证解决方案很快就变得难以支撑。
这种孤立的方法目前仍在许多面向消费者的场景中使用，其中用户通过提供特定于应用程序的用户名和密码进行注册。如果一个用户在多个站点上重复使用同一个密码，任何一个站点上的泄露都可能使该用户的数据在其他站点上受到威胁。如果用户为每个应用程序指定不同的密码，他们必须记住或安全地存储密码，或者依赖应用程序提供的帐户恢复过程的安全性。不管是哪种方式，消费者用户都会面临与企业用户之前经历的这种方法相同的一些不便。
目录服务-集中存储身份
随着时间的推移，为广泛的业务功能编写的软件越来越多。这促使人们需要一种更好的身份管理方法。许多公司实施目录服务，如LDAP或AD来存放和集中用户身份信息。目录服务针对频繁读取但很少修改的信息进行了优化，这通常适用于用户身份数据。应用程序能够使用目录服务来存储用户数据和凭据。应用程序还可以使用目录服务中的信息提示用户登录并验证输入的凭据。面向企业环境的大型现场商业业务应用程序 包括对这种方法的支持。这种集中化的方法与按应用程序的孤立方法相比有了显著的改进。
使用目录服务集中身份管理和访问提供了许多优势。支持目录复制功能的托管应用程序 在世界各地利用相同的身份信息，消除数据不一致的问题。应用程序之间可以使用相同的用户名和密码。集中式目录服务还提供了一个控制点，在这个控制点上可以实现密码策略或在必要时快速终止标识。因此，目录服务被广泛采用，至少在大公司是如此。
然而，尽管目录服务有很多优点，但也有一些缺点。目录服务本身并没有为用户维护任何类型的会话。目录服务中的身份信息集中通常意味着用户只有一个用户名和密码需要记住，但是用户仍然必须在每个应用程序的登录屏幕中输入凭据，因为每个应用程序都需要收集用户凭据并使用目录服务验证它们（在没有其他技术的情况下）。除了带来不便之外，这还将用户的密码暴露给应用程序。一个应用程序中的沦陷可能会使其他应用程序处于危险之中。当所有涉及的应用程序都在可信的公司网络中时，这种情况就已经够糟了。随着公司开始使用云应用程序，向云应用程序公开目录密码被其他人拥有会带来不可接受的风险。再一次，需要一个更好的解决方案！
早期SSO服务器
几种类型的身份和访问管理（IAM）或单点登录（SSO）服务器提供了进一步的改进。早期的SSO服务器利用了目录服务中的身份信息，但在目录顶部提供了一个层维护会话以记住已通过身份验证的用户的服务。它们的工作方式多种多样，但在一种典型的方法中，应用程序可以将用户的浏览器重定向到SSO服务器，以便在那里对用户进行身份验证，并以安全的、预先确定的方式接收身份验证结果。如果用户在第一个应用程序的身份验证后不久访问了第二个应用程序，则第二个应用程序会将用户的浏览器重定向到SSO服务器，并且SSO服务器会检测到用户的现有会话，并以成功状态将其重定向回应用程序，而不会再次提示用户提供凭据。
与目录服务相比，单点登录服务器的引入提供了许多优势。用户可以通过一次身份验证访问多个应用程序，因此受益匪浅。安全团队意识到，用户的静态目录密码只向SSO服务器公开，而不是向用户访问的每个应用程序公开。IT部门很高兴，因为它为他们在单一位置提供了实现身份验证策略和更强大的身份验证机制。
不幸的是，早期的SSO服务器在实践中存在一些缺点。应用程序和SSO服务器之间的交互在某种程度上是专有的，而SSO产品的实现往往非常耗时。另一个更重要的限制是单点登录依赖于cookie，由于浏览器对cookie访问的限制，这意味着解决方案可以在一个Internet域内工作，而不能跨域。由于许多公司开始采用外部软件即（SaaS）服务，这一限制就尤为明显。
联合身份WS-Fed
WS-Federation（简称: WS-Fed )联合框架属于Web Services Security(简称: WS-Security、WSS: 针对web-service安全性方面扩展的协议标准集合) 的一部分。WS-Federation规范采用了XML以及其他Web服务标准，从而可以使开发者能够实现在不同环境下的网络安全管理及建立相互协调信赖关系的目的。
2002年4月11日，微软、IBM和VeriSign三公司联合发表了Web服务的新安全规格“WS-Security”和Web安全蓝图“Security in a Web Services World”。在当时的安全蓝图说明中就包括了WS-Federation规范的基本轮廓。并于2003年7月9日发布规范的说明草案。
2009年，WS-Fed1.2规范正式作为OASIS的标准发布。该版本提供了“可以向在其他领域管理其身份的安全主体提供对在一个领域中管理的资源的授权访问”的机制，该标准得到了微软ADFS服务器以及许多其他商业SSO产品和服务的支持，提供了与SAML2.0的web单点登录和联合功能类似的功能。
WS-Fed可用于完成从身份提供者到服务提供者的联合单点登录。在联合单点登录中，用户向身份提供者进行认证。服务提供者使用由身份提供者断言的身份信息，标准规定了数据交换和消息处理。该标准在微软自己的产品中得到了广泛的应用和推广，但是，该标准是基于SOAP的，整个协议虽然功能强大，细节考虑周全，但实现起来会比较重，因此，除非为了能和微软的服务整合，才会优先考虑该协议。
而对于互联网或是SaaS服务厂商，更愿意选择SAML。
联合身份 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应用程序中更好地控制员工身份的企业提供了一个极好的解决方案。
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的协议奠定了基础，我们稍后将介绍这个协议。
互联网时代OAuth2.0
在介绍OpenID Connect协议之前，我们首先要了解下授权协议OAuth，它并非是一个认证的协议，而是一个授权的协议，即无法用来认证使用者的身份，而是在知道使用者身份以后来颁发对于该使用者的权限。
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，一个非正式RFC。 2012年10月，OAuth 2.0发布，正式发表为RFC 6749。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消息流，其设计目标是“使简单的事情变得简单和复杂的事情成为可能”。与任何先前的身份协议相比，开发人员集成起来是更加容易。
OpenID+OAuth 2.0=OpenID Connect
OpenID Connect允许开发人员跨网站和应用程序验证用户，而无需拥有和管理密码。它允许所有类型的客户端（包括基于浏览器的JavaScript和移动应用程序）启动登录流，并接收有关登录用户身份的可验证断言。
OAuth2.0授权服务器能够对用户进行身份验证，但该框架也没有提供一种标准的方法来将经过身份验证的用户的身份安全地传递给应用程序。OIDC为这一需求提供了解决方案。OIDC被设计为OAuth2.0协议之上的一个层，以标准格式向应用程序提供有关经过身份验证的用户的身份的信息。这为用户身份验证和API授权的应用程序提供了一个解决方案。
Google、PayPal和Yahoo等广泛使用的社交媒体/服务提供商实现了OIDC，为面向消费者的身份验证服务提供了解决方案，但协议中没有任何内容将其限制在面向消费者的场景中。事实上，OIDC的设计可以同时面向消费者用户和企业员工的场景。
OIDC为用户、应用程序开发人员和身份提供者提供了好处。网站开发人员可以将实现身份验证和密码重置逻辑的工作委托给OIDC提供者。用户从中受益，因为他们可以利用一个帐户登录到多个站点，而无需向其他站点公开其帐户凭据。用户拥有更少的用户名和密码来管理和享受单点登录。如果OIDC支持能够吸引更多的用户使用他们的平台，OIDC提供商可能会从中受益。OIDC提供了在SAML2.0中很有吸引力的Web单点登录的优点，同时与OAuth2.0结合，又让它提供了兼具身份验证和现代应用程序所需的API授权的解决方案。
可以预见，随着微服务、云原生的迅猛发展，OIDC的应用将会越来越广泛。
前几节简要介绍了管理身份和验证用户的不同解决方案和诞生的原因，相信大家已经对于为何使用标准协议有了一定的理解。最后，我们将简单再陈述下使用标准协议的好处。
为何使用标准协议
接下来的几章将描述三种常用的行业标准身份协议及其工作原理。但首先，为什么要使用行业标准协议？
首先，作为开放标准，这些协议已经被许多人仔细检查过是否存在缺陷，所以比起你自己发明的东西，它们不太可能有漏洞。
其次，这些协议被广泛使用，提供了应用程序和支持这些协议的服务提供商之间的互操作性。如果您希望从Google、微博等开放服务访问用户配置文件数据，则必须使用这些服务实现的标准协议。类似地，如果您的应用程序将由企业使用，企业可能希望您的应用程序使用这些协议之一。
第三，为身份验证设计的协议支持单点登录，这为您的用户提供了方便。
最后，使用现有协议可以节省时间，因为许多编程语言都提供支持它们的SDK。
因此，使用行业标准身份协议有四个很好的理由！
如果您对身份验证领域还比较陌生，那么首先学习这些协议可能会让您感到有点畏缩，并且可能会尝试自己发明一个更简单的身份验证方案。对此我们有两个词：“不要！”我们希望这本书能让你更容易理解如何使用这些协议。我们不想阻碍创新，但在认证领域的创新应该谨慎行事。你的创新最好把精力花在应用程序的核心价值主张上！
本章重点回顾
- 身份管理、身份验证和授权方法不断发展 随着时间的推移。早期的方法通常涉及特定于应用程序的标识和凭证。
- 身份集中使用目录服务的数据启用了单个标识和凭据，但必须输入 由一个用户进入每个应用程序（在没有其他补充技术的情况下）。
- 单点登录服务器提供了会话管理，因此用户可以一次登录并通过一次身份验证访问同一域中的多个应用程序。
- SAML2.0和WS-Fed提供了跨域的单点登录和联合身份。
- OpenID提供了一个面向消费者的解决方案。
- OAuth2.0提供了一个授权应用程序调用API的解决方案。
- OIDC在OAuth之上提供了一个层 2.0用于对用户进行身份验证，并以标准格式向应用程序返回有关已验证用户的身份断言信息。