当互联网应用越来越多，每个应用程序都实现了自己的身份存储、认证和授权，用户需要在应用上反复的注册与登录，体验糟糕，用户身份信息无法在多个应用间共享与同步。当使用企业应用时，企业提供了一系列应用，尽管是同一用户操作，但还是不得不切换注册与登录。
是否可以有那么一种方式，我在某个代理网站注册一个账号，如果登录其他网站时，其他网站可以到代理网站去获取信息。只要代理网站足够富有生命力，那么总是可以省略很多乏味的注册登录流程。
这些想法在技术的发展过程中出现了，如WS-Federation、SAML2.0、OpenID、OAuth、OIDC...
还有一些修订和扩展，此处就不体现了，主要是想聚焦于OpenID和OAuth是不一样的。
- OpenID是面向身份认证，对用户身份进行认证判断是否有效。
- OAuth是面向授权过程，在已知当前用户身份合法后，控制用户能够访问的资源，考虑保护被访问的资源。
OpenID是一个去中心化的网上身份认证系统。对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统认证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者（identity provider, IdP）的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。OpenID既解决了注册问题而又不需要依赖于中心性的网站来确认数字身份。
OpenID给用户提供一个统一网络身份，遵守OpenID网络身份，遵守OpenID协议的应用网站（在OpenId术语里叫Relying Parties，即RP）需要用户登录时，引导用户到第三方OpenID身份提供方（OpenId术语里叫OpenID identity provider，即OP）去认证，认证通过即登录成功。这样就省去了每个应用网站注册、登录的烦恼与乏味。解决了最开始提到的一个问题，各应用需要独立完成注册与登录流程，需要实现与维护独立的用户数据库。
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 Core 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应用、桌面应用、手机和智能设备提供专门的认证流程。
OpenID团队本来希望用户使用OpenID来进行身份认证， 但因为授权过程包括认证过程作为一部分，所以授权意味着经过了认证这一过程。由此，一些用户选择了OAuth身份认证的简易性，并且由于“管理用户凭据的任务可以委托给外部服务”以及“因为新用户注册过程可以省略，使用该服务的障碍变得更低”等优点而迅速占据主导地位，使用OAuth2.0作为身份认证的趋势变得流行。
OpenID团队不得不承认用户更喜欢OAuth2.0，因此，他们在OAuth之上定义了一个新的身份认证规范OpenID Connect(OIDC)，这个规范基于OAuth2.0进行了小幅扩展，在OAuth2.0上构建了身份层，使其可用作身份认证协议。
即OpenID Connect (OIDC) 是基于 OAuth 2.0 构建的身份认证协议。
OpenID OAuth 2.0=OpenID Connect
- Claim: 声明信息，简要格式展示(如身份证上格式)。
- Claims Provider: 声明信息提供方(如OAuth2.0中的Authorization Server能够返回Id token，其中携带着声明信息)。
- End-User(EU): 人类参与者(完成认证活动的人)。
- ID Token: 包含EU身份信息的声明(Claim)，以JWT(Json Web Token)格式进行存储传递。JWT具有自包含性、紧凑性和防篡改机制等特点。使得ID Token可以安全的传递给第三方应用并且容易被验证。
- OpenID Provider (OP): 提供身份认证的服务方，OAuth2.0中的Authorization Server(授权服务器)，用来提供身份认证服务以及返回Claim信息给第三方应用(Relying Party)。
- Relying Party (RP)：受信任的第三方应用(OAuth2.0中的Client)，需要EU完成鉴权，并从OP处获得Claim信息的应用。
- UserInfo Endpoint：用户信息的接口，当RP使用Access token请求该接口时，能够返回当前用户的身份信息。
OIDC由一系列规范文档组成，包括一个核心文档和多个可选支持的文档来提供扩展支持：
- Core：必选。定义了OIDC核心的功能，在OAuth 2.0之上构建身份认证，以及使用声明(如身份证上的简要描述)方式来传递用户的信息。
- Discovery：可选。定义了第三方应用如何动态发现OIDC服务提供方元数据文档(比如提供的服务地址，采用的加密方法，支持的授权类型等等）。
- Dynamic Registration：可选。定义了第三方应用如何注册到OIDC身份提供方。
- OAuth 2.0 Multiple Response Types：定义了几种新的为OAuth2.0响应方式(原来常见的授权码code、隐式授权token基础上增加了id_token以及混合code、token和id_token的方式)。
- OAuth 2.0 Form Post Response Mode：可选。在OAuth2.0的响应参数上扩展了OIDC所需的参数。提供了基于form表单响应信息的模式，使用post请求类型传给第三方应用，响应参数以application/x-www-form-urlencoded格式存储body中。
- RP-Initiated Logout: 可选。定义了第三方应用如何注销当前登录用户的机制。
- Session Management：可选。定义了如何管理OIDC上已登录用户的会话数据，以便当OP上的用户注销时，也能够方便在RP上注销。
- Front-Channel Logout：可选。基于前端的注销机制，使得第三方应用不需要嵌入认证服务方的iframe来注销。
- Back-Channel Logout：可选。基于后端的注销机制，定义了RP和OP直接如何通信来完成注销。
- OpenID Connect Federation: 可选。定义了如何在OP和RP间建立可靠的信任的机制。
- Initiating User Registration via OpenID Connect: 可选。提供一种方式允许在RP指示下，能够在OP上注册用户的机制。
如下图所示，上部分描述OIDC的协议簇，以及其中最为核心的Core规范。下部分是作为支撑OIDC的其他协议规范。
对于这些协议来讲，可能看着就难受，简要了解个概念即可，实际开发时这些都会逐渐浮出水面。
- OpenID Connect执行许多与OpenID 2.0相同的任务，但是API更友好且可使用在原生应用和移动应用。
- OpenID Connect 定义了用于可靠签名和加密的可选机制。
- OAuth 1.0a和OpenID 2.0的集成需要扩展，而OIDC本身集成了OAuth2.0。
OIDC仍然使用OAuth中的授权服务器将用户身份认证信息以Id token的方式给到第三方应用，第三方应用可以验证用户标识并从中获取用户的基本信息以及通过OAuth2.0的授权流程访问用户的详细信息。如下图所示，对于用户认证部分采用认证协议如WS-Fed、OIDC等，对于资源的访问控制以OAuth2.0协议为主。
