从2000年开始，在如何存储和使用身份信息、保障用户能够访问应用程序、跨应用的数据共享一直在不断升级。每隔几年时间，就会有新的需求和挑战，当然也会有对应新的方案，每一次升级都解决了一些问题，但也带来了新的问题。
了解过去，以示未来
不同时期的身份技术具有特定突出的优点，当然也有缺点，这些优点和缺点可以帮助您更好的评估项目的身份解决方案。
身份发展概要
按照时间回顾下身份发展的历史。
第一阶段：石器时代，各个应用使用独立的身份体系、独立进行认证和存储身份，后来基于Cookie进行内部应用的单点登录。
第二阶段，电气时代——联合身份，2003年为了解决企业应用的联合认证的问题，微软联合、IBM等传统IT巨头发起了基于WS*系列标准之上构建的WS-Federation1.1版本，但这一协议因为过于重，除了得到微软的积极拥护以外，其他软件厂商响应屈指可数。因此在2005年，SAML2.0横空出世，其协议的相对WS-Fed更为简洁明了，更适合SaaS应用的发展，得到了SaaS厂商的支持。
第三阶段，互联网时代——面向消费者共享身份，随着互联网、移动互联网的相继爆发，OpenID和Oauth应运而生，并且得到广泛的应用。在2012年以前，互联网的应用之间的信息交互较少。随着互联网爆发式增长，让资源相互调用的需求迅猛增长，Oauth2.0就此诞生，让互联网应用之间的交互变得更加便捷。
第四阶段，云时代——身份和授权标准化，因为技术的演进，对于API的授权需求越来越多，2014年基于OpenID和Oauth2.0，OIDC于2014年发布，谷歌、微软、PingIDentity纷纷转向这一新的协议。微服务、云原生这几年概念火热，可以预见OIDC的应用将会越来越广泛。
石器时代
独立存储身份
在石器时代的计算机应用程序中，每个应用程序通常实现自己的身份存储库、身份验证和授权。
这种烟囱式应用构建让90%的应用都存在相同安全风险。用户的登录体验是割裂的，用户的身份信息无法获得同步。在企业场景下，当只有几个应用程序时，用户对数据完整性问题的恼怒和必须记住的几个密码体验就足够糟糕了。然而，随着企业中应用程序数量的增长，让每个应用程序实现自己的筒仓式身份存储库和身份验证解决方案很快就变得难以支撑。
这种孤立的方法目前仍在许多面向消费者的场景中使用，其中用户通过提供特定于应用程序的用户名和密码进行注册。如果一个用户在多个站点上重复使用同一个密码，任何一个站点上的泄露都可能使该用户的数据在其他站点上受到威胁。如果用户为每个应用程序指定不同的密码，他们必须记住或安全地存储密码，或者依赖应用程序提供的帐户恢复过程的安全性。
目录服务
很快，人们发现，如果采用集中式的目录来存储用户的身份信息将带来无可比拟的优势。
支持目录复制功能的托管应用程序 在世界各地利用相同的身份信息，消除数据不一致的问题。应用程序之间可以使用相同的用户名和密码。集中式目录服务还提供了一个控制点，在这个控制点上可以实现密码策略或在必要时快速终止标识。因此，目录服务被广泛采用，至少在大公司是如此。
目录服务对于身份管理带来了极大的提升，但是目录服务没有维护任何的应用会话。因此，仍然没有解决用户反复输入身份信息、授权等等问题。同时，也将用户的凭据暴露给了应用。一个应用程序中的沦陷可能会使其他应用程序处于危险之中。当所有涉及的应用程序都在可信的公司网络中时，这种情况就尚且可以容忍。随着公司开始使用云应用程序，向云应用程序公开目录密码被其他人拥有会带来不可接受的风险。再一次，需要一个更好的解决方案！
电器时代-联合身份
在身份目录的基础上，构建一层身份会话层，用于维护身份登录的的信息，理所当然的成为目录服务的改进方案，即单点登录-SSO。
与目录服务相比，单点登录服务SSO的引入提供了许多优势。用户可以通过一次身份验证访问多个应用程序，因此受益匪浅。用户的静态目录密码只向SSO服务器公开，而不是向用户访问的每个应用程序公开。IT部门很高兴，因为它为他们在单一位置提供了实现身份验证策略和更强大的身份验证机制。
早期的单点登录服务依赖于cookie，由于浏览器对cookie访问的限制，这意味着解决方案可以在一个Internet域内工作，而不能跨域。由于许多公司开始采用外部软件即（SaaS）服务，这一限制就尤为明显。
接下来可想而知，对于SSO的改进，就成为很多大公司（如微软、IBM等）创新的方向。
身份开始逐渐走向标准化，这里不得不提到的是OASIS（Organization for the Advancement of Structured Information Standards）结构信息标准化促进组织。其中，WS-Fed和SAML均捐赠了给OASIS。
联合身份-WS-Fed
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产品和服务的支持。
WS-Federation（简称: WS-Fed )联合框架属于Web Services Security(简称: WS-Security、WSS: 针对web-service安全性方面扩展的协议标准集合) 的一部分。WS-Federation规范采用了XML以及其他Web服务标准，从而可以使开发者能够实现在不同环境下的网络安全管理及建立相互协调信赖关系的目的。
不用看协议的具体内容，光看到协议的框架，就可以感知到整个协议的功能之强大，细节之周全。然而，这也意味着实现起来会比较重，因此，除非为了能和微软的服务整合，才会优先考虑该协议。所以，该协议主要用于微软自己的生态。
而对于互联网或是SaaS服务厂商，更愿意选择SAML。
联合身份 SAML2.0
SAML 2.0在2005年三月正式代替SAML 1.1成为OASIS标准。来自超过24个公司及团体的大约30人参与了SAML 2.0的创建。尤其是，自由联盟将身份联合框架规范（ID-FF）贡献给OASIS，后者成为了SAML 2.0规范的基础。
它提供了跨域和联合身份的web单点登录解决方案。这恰好适合于使用SaaS应用程序的企业, SAML 2.0为需要在SaaS应用程序中更好地控制员工身份的企业提供了一个极好的解决方案。
SaaS应用程序可以将企业用户重定向回企业身份验证服务（称为身份提供者（IdP））进行身份验证。身份联合基于网络跨域的单点登录(SSO)， 以便于减少向一个用户分发多个身份验证令牌的管理开销。用户也只需记住一个用户名/密码，而无需反复登录。无论是对内部和外部应用，SAML赋予企业一个集中控制点，如果需要，可以在企业身份提供者处快速关闭一个用户的访问权限。密码策略和多因素身份验证也可以在一个地方实现，通过这种方式，SAML2.0解决了企业的许多身份问题。
SAML2.0的不足之处
尽管被广泛采用，但是SAML2.0并不是万能的。该协议被设计为覆盖许多场景，使得配置和实现仍然复杂。虽然SAML2.0在企业环境中被广泛采用，但是没有一个可行的业务模型来解决面向消费者的场景。另一个限制是SAML2.0只解决了身份验证问题，而没有解决API的授权问题。应用程序正在向基于微服务、API的体系结构发展，正如通常实现的那样，SAML2.0解决了对用户进行身份验证的问题，但对API授权没有帮助。
互联网时代的身份
SAML2.0只在面向员工的场景中采用，消费者用户仍然被迫在每个面向消费者的网站上重新注册。因此，“以用户为中心”的身份解决方案正在萌芽，并由此产生了一个称为OpenID的协议。
OpenID
OpenID是一个去中心化的网上身份认证系统。对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者（identity provider, IdP）的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。OpenID既解决了注册问题而又不需要依赖于中心性的网站来确认数字身份。
与面向组织控制的身份提供者 （Saml2.0和WS-Fed）不同，OpenID则提供了面向用户控制的消费者身份的协议。那么互联网时代的消费者身份问题被解决了，但是有新的问题需要解决，即消费者的数据权限，并为此产生了Oauth 授权协议。
Oauth2.0
Oauth2.0 并非是一个认证的协议，而是一个授权的协议，即无法用来认证使用者的身份，而是在知道使用者身份以后来颁发对于该使用者的权限。
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。
云时代的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的应用将会越来越广泛。
过去十多年中身份的协议不断演进和修改，才成为今天的标准和规范，在演进的过程中，这些协议被无数开发者仔细检查过是否存在缺陷，所以比起自定义的流程，它们更加的安全，不太可能有漏洞。同时，遵循这些规范，也能增加了互操作性，与他人兼容，更符合方便用户的视角。
当然，这些协议因为使用众多，很容易找到对应的SDK或者开发包，为开发者节约更多的时间。