OpenID Connect具有规范 ，在中心上有教程，文章，而在中心上没有 雕刻另外一步一步的指令是毫无意义的，它从迷惑到通过授权和认证进行工作。 以下文本的任务是不同的，用于描述基础规范的思想（不止一个）。
我不会立即跳到本文的主题，但是我将以简单的事物和许多显而易见的事物开始。 我将继续介绍他们的开发方式以及根据客户要求进行的总结。 我将以历史的方式，即以他的出生方式来对待他。
1。
最小的任务就是不让任何人使用任何资源。 我们使用用户名/密码将其关闭，谁知道正确的用户名和密码对将访问资源，而谁不知道-不。 这就是所谓的身份验证 ，因为它不仅可以使用带有密码的登录名（例如，SMS代码或硬件USB密钥），而且这些细节对于我们的主题不是必不可少的。 我还将省略强制性段落，该段落涉及以开放形式在Internet上传输密码的危险，对此我们所有人都不喜欢基本访问身份验证 。
最好注意这一点：没有用户喜欢输入带有密码的登录名。 SMS中的代码再好不过了，而USB密钥简直令人讨厌。 为了不强制用户为每个请求输入带有密码的登录名，服务器响应于此请求，发送了乱码行，称为会话密钥 。 然后，此密钥紧贴客户端的每个服务器请求（通常带有HTTP标头，但这不是必需的），然后服务器检查它是否具有这样的会话。
具有按键的会话-根据定义，现象是暂时的，会话生命周期的黄金比率大约是“打开浏览器选项卡，但不超过一天”
2。
他们让任何人进入-很好。 现在，您需要确切了解我们放开了谁。 不仅可以推断出他在右上角输入的名字，还可以决定允许他输入什么，不允许输入什么。
这就是所谓的授权 。 我不确定您的身份，但是我一直将其与身份验证混淆。 为了避免混淆（相对授权的规则，“授权”），他们用“作者”，“作者”一词写在书的封面上，而从不在那里写“作家联盟的有效成员”。 作者永远是一个非常具体的人。 因此，授权是一个过程，当我们通过登录名和密码了解确切由谁启动时。
3。
好啦 我们有一个网站，该网站上有个秘密，在秘密部分的入口处，我们要求输入密码，每个密码仅显示他的秘密，而我们不显示陌生人。 生活不会停滞不前，我们还有另一个站点。 在这里，我们再次遇到第1点的问题，没有人喜欢输入用户名和密码！ 您可以合并用户群，这将使他们免于两次注册的麻烦，但是如何避免他们在入口重新输入登录名和密码呢？ 考虑到存在“ 相同来源策略”之类的问题（当然，我们的站点位于不同的域中，那么带有会话密钥的cookie彼此之间是不可见的）？ 在此，我将着重介绍这一点，以强调这一点。
4。
SSO ， 单一登录 -无论采用哪种实现，Microsoft Kerberos，SAML或OAuth 2.0 ，在上面构建OpenID Connect的地方，实际上我都会在这里写信给您，实际上，总会有同样的事情：有一个单独的服务器授权 ，任何想要授权用户的人都会将该用户重定向到该用户。 如果用户已经被授权，则启动该会话，然后他立即从授权服务器飞回并到达他想要的位置。 如果未授权，则授权服务器通常会通过请求使用密码登录来最大程度地解决此问题，如果解决方案成功，则会将用户送回。
而且，可以说目前的SAML解决方案已经过时了。 Kerberos通常是完全独立的封闭式Microsoft魔术，它远远超出了HTTP协议的范围。 好吧，我们将专注于此。 然后我们讨论下一个问题。
已经存在一种可以理解的工作方案-在任何无法理解的情况下，将用户发送到授权服务器，让他决定如何处理他并返回现成的答案。 但是授权服务器如何准确地告诉其他服务器该用户已被授权？ 在这里，我们再次回到第一段的想法，即会话密钥。 让我们回到基础上：会话密钥的存在是授权的标志，会话密钥本身为用户信息打开了大门，而对于会话信息，您将不会相信。 因此，授权服务器授权会话密钥并将其提供给另一台服务器。
但是，现在它不再称为会话密钥，而是令牌 。
更准确地说，（根据OAuth 2.0协议，在其之上编写了OpenID Connect），它们是两个令牌-Access Token （将其作为祖父裁剪的会话密钥挂钩到所有请求）和Refresh Token （在退出时更新Access Token）。
总结小计。 服务器没有向用户询问用户名和密码，而是将其发送到另一台服务器，即单独的授权服务器。 他完成了所有工作，然后给出了第一个令牌。 在这种情况下，应用程序是经过授权的，可移动的，有时甚至是桌面的。，它们只是不进行任何重定向，它们只是发送带有用户名和密码的JSON授权服务器，然后他会向他们发送令牌。
移动和桌面应用程序可以做到这一点。 由于某些原因，它们被认为比网络更安全，但是网络的生活更为复杂。
6。
一方面，它并不复杂，反而更简单。 您可以进行重定向，而不必呈现呈现登录密码表单。 另一方面，我确实真的不想将令牌清楚地拖过浏览器。 这几乎与基本访问身份验证中的未加密密码一样令人恶心。 但是没有人愿意重蹈覆辙。
该问题没有解决方案，因此非常优雅，但是可以正常工作。 首先，一切照常进行，切换到授权，授权本身。 然后，当需要返回令牌时，将发生反向重定向。 但是，一次性代码会附加在返回地址上，而不是令牌。 一次性代码仅由授权服务器在此特定时刻生成。 他的寿命很短。 刚收到一次一次性代码后，另一台服务器应收起裙子，睁大眼睛，再次冲向授权服务器，以便从一次性代码中接收令人垂涎的令牌。
授权服务器上有用于标记的代码的旅行专用资源。 根据规范，它不接受GET，而是POST。 这以某种方式向我们暗示了该请求不应从浏览器发出，而应从服务器发出。
出于同样的原因，在任何自重的CORS授权服务器上，禁止POST请求。
7
顺便说一句，您还记得认证和授权吗？ 身份验证是指仅允许某人通过登录名和密码进入，或者不允许某人进入。 授权是在已经启动时，他们开始了解自己确切地启动了谁。
您还记得OAuth 2.0吗？ 我在上面几次提到它，作为OpenID Connect的某种基础。
您还记得OpenID Connect吗？ 这篇文章只是他愚蠢。
因此， OAuth 2.0是身份验证。 前面描述的整个过程由三个参与者，一个密码，一个代码和一个令牌组成，有些混乱，与认证有关，只是让某人在某个地方运行而已。 OAuth 2.0协议。
OpenID Connect是授权。 也就是说，他在OAuth中添加了那些让他们放手的部分。
为此，将另外一个令牌添加到令牌列表中，这称为ID令牌 。 那些关注链接的人可能会惊讶地发现它上没有任何令牌ID。 让我们惊讶的是， ID令牌是作为与访问令牌和刷新令牌相同的JSON以base64编码的嵌套娃娃返回的JWT 。 无论如何，您想知道的有关用户的所有信息都在他身上。
授权服务器上还有一个名为userinfo的特殊资源，您可以在其中使用Access Token敲门，并获得与Token ID中相同的JSON作为响应。 但是，如果令牌ID已经存在，为什么需要它呢？ 向规范作者提问。
OpenID Connect还包含用户信息各个字段的描述。 在授权期间或之后的任何时间，如何获得此信息。 并说明用户如何以及何时允许您使用此信息。
还是不允许。 因此，简而言之，就是设计了OpenID Connect 1.0。
8。
协议中的一些金属丝。 我希望您现在已经厌倦了阅读这篇文章，以免仅仅通过目不转睛地关注此项目。 在这里，我将提到规范中的参数，这些参数会带来一些语义上的负担，但它们与构思本身的实现没有直接关系。 基本上，它们可以增加安全性，或者在必要时允许您将某些信息从流程中的一个参与者转移到另一参与者。
客户ID和客户机密 。 使用OpenID Connect协议语言的客户端根本不是浏览器，而是需要授权用户的另一台服务器。 假设您有一个网站，并且想要通过Facebook将时尚的授权附加到该网站。 并通过googol。 并没有通过Twitter流行。 在代码中实现协议是不够的。 您还需要在Facebook，Google和Twitter上注册，但不是作为用户而是作为作为服务器可以使用其授权的客户。 注册时，您将从有条件的facebook收到客户端ID和客户端密钥。 当要求授权时，请发送客户ID。 而且，当您使用一次性令牌代码时，Client Secret也将要求您。
重定向URI 。 这里的一切都很简单。 当将用户发送到有条件的Facebook登录时，您需要告诉Facebook授权后在哪里向他返回代码和令牌。 当然，您仍然给他您的客户ID。 但是，单独的重定向URI允许您在授权不同用户后将不同用户重定向到不同页面，例如将admin重定向到管理面板，将普通用户重定向到其个人页面。 实用。 此外，在条件Facebook上的客户端设置中指定的可能的重定向URI允许列表是一项额外的安全措施。
适用范围 。 这是服务器希望从授权服务器了解用户的列表。 列表中的值用空格分隔，在其中必须使用openid，然后阅读规范。
状态 。 还记得一次性代码，通过它发行令牌，就像电子队列中的票证一样？ 因此，状态是一个代码，相反，如果授权服务器将代码提供给另一台服务器，使其很快将其返回，则该状态将授权服务器授予另一台服务器以在重定向时将其返回。 据我了解，如果另一台服务器已经设法创建自己的会话，以便在所有这些重定向中都不会丢失，则需要他。
还有其他参数，例如授权请求的类型和令牌生存期，但是要了解为什么不需要它们。
总而言之。 我真的希望不要太周到和集中地阅读上面的内容，以帮助您了解一些现代访问控制协议的基础。 但是，开始实施或只是配置其中之一，打开规范，找到一个不错的教程，并仔细听每个单词和每个字母。 让对思想的理解唤醒您的直觉。 直觉，每当您错过一个乍一看并不太重要的参数或设置时，就让您咬在冠上，并留出一个汗水嬉戏的小手的空隙。
请记住，这都是相同的安全性，它的规则，不管看起来多么愚蠢和毫无意义，都是鲜血书写的。 好吧，也许没有血迹，毕竟这不是铸造厂的安全措施，但是金钱和声誉是可以肯定的，金钱和声誉也不是你应该轻易扔掉的东西。
感谢JM ，您所阅读的文字比我写的文字要好得多。
祝您好运，并且别忘了按时续签您的证书。