然而，到目前为止，所有内容只是这篇文章的序言。开发人员的技术内容从这里开始。第一个主题是OAuth 2.0和OpenID Connect之间的关系。

在我完成RFC 6749（OAuth 2.0授权框架）的实施之后，我注意到了OpenID Connect的存在。当我收集有关OpenID Connect的信息时，我认为我应该实现该功能，因此请阅读OpenID Connect Core 1.0和其他相关规范。在阅读之后，我得出的结论是“所有人都应该从头开始重写” 。

OpenID Connect网站称“OpenID Connect 1.0是一个基于OAuth 2.0协议的简单身份层。 ”这给人的印象是OpenID Connect可以在现有的OAuth 2.0实现之上轻松无缝地实现。然而，事实却完全不同。恕我直言， OpenID Connect实际上是OAuth 3.0 。

有许多与OpenID Connect相关的规范，它们令人费解，难以破译它们。在我能够掌握整个画面之前，我几乎疯了，不得不读了三遍。与OpenID Connect规范相比， RFC 6749可以说很容易。

5.响应类型

特别是，与现有实现冲突的是处理请求参数response_type的方法。可以肯定的是， RFC 6749声明请求参数可能需要多个值，但这是将来的可能性。如果我们直接读取RFC 6749 ，则response_type是代码或令牌。几乎不可能想象这两个是同时设置的。这是因为该参数用于确定处理来自客户端应用程序的请求的流程。具体而言，当response_type的值是代码时使用授权代码流，并且当值是token时使用隐式流。谁能想象这些流量是混合的？即使可以想象它，我们应该如何解决流量之间存在的冲突？例如，授权代码流要求将响应参数嵌入到重定向URI（4.1.2 。授权响应）的查询部分中，而隐式流要求将响应参数嵌入到片段部分中（4.2.2 。访问令牌）响应），并不能同时满足这些要求。