笔记。 翻译。：Okta 的这篇精彩文章解释了 OAuth 和 OIDC (OpenID Connect) 如何以简单明了的方式工作。 这些知识对开发人员、系统管理员，甚至是流行网络应用程序的“普通用户”都有用，这些应用程序很可能还与其他服务交换机密数据。
在 Internet 的石器时代，服务之间共享信息很容易。 您只需将您的登录名和密码从一项服务提供给另一项服务，这样他就可以进入您的帐户并收到他需要的任何信息。
“给我你的银行账户。” “我们保证只要有密码和钱，一切都会好起来的。 老实说，老实说！” *嘻嘻*
恐怖！ 任何人都不应该要求用户共享用户名和密码， 证书, 与另一项服务。 无法保证此服务背后的组织会保护数据安全并且不会收集不必要的个人信息。 这听起来很疯狂，但一些应用程序仍在使用这种做法！
今天有一个单一的标准，允许一项服务安全地使用另一项服务的数据。 不幸的是，这些标准使用了很多行话和术语，这使他们的理解变得复杂。 这个材料的目的是用简单的插图来解释它们是如何工作的（你觉得我的画像孩子们的涂抹吗？哦好吧！）。
顺便说一句，本指南也有视频格式：
女士们，先生们，欢迎：OAuth 2.0
是一种安全标准，允许一个应用程序获得访问另一个应用程序中的信息的权限。 颁发许可证的步骤顺序 [允许] （ 同意 [同意]) 经常打电话 授权 [授权] илидаже 委托授权 【委托授权】. 使用此标准，您允许应用程序代表您读取数据或使用另一个应用程序的功能，而无需提供您的密码。 班级！
例如，假设您发现了一个名为“每日不幸双关语”的网站 [今天可怕的双关语] 并决定在上面注册，以便在手机上以短信的形式接收每日双关语。 您真的很喜欢这个网站，并决定与所有朋友分享。 毕竟，每个人都喜欢令人毛骨悚然的双关语，对吧？
“今天不幸的双关语：听说过失去左半身的人吗？ 现在他永远是对的！” （近似翻译，因为原文有自己的双关语 - 近似翻译。）
很明显，不能给联系人列表中的每个人写信。 而且，如果你有一点像我，那么你会竭尽全力避免不必要的工作。 幸运的是，Terrible Pun of the Day 可以自己邀请所有的朋友！ 为此，您只需要打开对联系人电子邮件的访问权限——网站本身会向他们发送邀请（OAuth 规则）！
“每个人都喜欢双关语！ - 已经登录？ “您愿意允许 Terrible Pun of the Day 网站访问您的联系人列表吗？ - 谢谢你！ 从现在开始，我们将每天向您认识的每个人发送提醒，直到时间的尽头！ 你是最好的朋友！”
- 选择您的电子邮件服务。
- 如有必要，请转到邮件站点并登录您的帐户。
- 授予 Terrible Pun of the Day 访问您的联系人的权限。
- 返回 Terrible Pun of the Day 网站。
如果您改变主意，使用 OAuth 的应用程序还提供了一种撤销访问权限的方法。 一旦您决定不再希望与 Terrible Pun of the Day 共享联系人，您可以转到邮件站点并将该双关语站点从授权应用程序列表中删除。
OAuth 流程
我们刚刚经历了通常所说的 流动 [流动] OAuth。 在我们的示例中，此流程由可见步骤和几个不可见步骤组成，其中两个服务就安全信息交换达成一致。 前面的 Terrible Pun of the Day 示例使用最常见的 OAuth 2.0 流程，称为“授权代码”流程。 【“授权码”流程】.
在深入了解 OAuth 的工作原理之前，让我们先谈谈一些术语的含义：
- 资源所有者:
是你！ 您拥有您的凭据、您的数据，并控制可能在您的帐户上执行的所有活动。 - 客户:
一个应用程序（例如 Terrible Pun of the Day 服务）想要代表 资源所有者'一个。 - 授权服务器:
知道的应用程序 资源所有者'a 并且你在其中 资源所有者'一个已经有一个帐户。 - 资源服务器:
应用程序编程接口 (API) 或服务 客户 想代用 资源所有者'一个。 - 重定向 URI:
那个链接 授权服务器 将重定向 资源所有者'并在授予许可后 客户'在。 它有时被称为“回调 URL”。 - 响应类型:
预期收到的信息类型 客户. 最常见的 响应类型'ohm 是代码，即 客户 期望收到 授权码. - 范围:
这是所需权限的详细说明 客户'y，例如访问数据或执行某些操作。 - 同意:
授权服务器 贝雷帽 领域要求 客户'om，然后问 资源所有者'a, 他准备好提供 客户'有适当的权限。 - 客户ID:
此 ID 用于识别 客户'a on 授权服务器'e. - 客户机密:
这是只有自己知道的密码 客户'你和 授权服务器'在。 它允许他们私下共享信息。 - 授权码:
有效期短的临时代码， 客户 提供 授权服务器'y 作为交换 访问令牌. - 访问令牌:
客户端将用来与之通信的密钥 资源服务器嗯。 一种徽章或钥匙卡，提供 客户'有权请求数据或执行操作 资源服务器'代表你。
注意: 有时授权服务器和资源服务器是同一台服务器。 但是，在某些情况下，这些可能是不同的服务器，即使它们不属于同一组织。 例如，授权服务器可能是资源服务器信任的第三方服务。
现在我们已经介绍了 OAuth 2.0 的核心概念，让我们回到我们的例子，仔细看看 OAuth 流程中发生了什么。
- 你 资源所有者, 你想提供 Terrible Pun of the Day 服务 (客户y) 访问您的联系人，以便他们可以向您的所有朋友发送邀请。
- 客户 将浏览器重定向到页面 授权服务器'a 并包含在查询中 客户ID, 重定向 URI, 响应类型 和一个或多个 领域 （权限）它需要。
- 授权服务器 验证您，必要时询问用户名和密码。
- 授权服务器 显示一个表单 同意 （确认）以及所有的列表 领域要求 客户嗯。 你同意或拒绝。
- 授权服务器 将您重定向到该站点 客户'a, 使用 重定向 URI 同 授权码 （授权码）。
- 客户 直接与 授权服务器'ohm（绕过浏览器 资源所有者'a) 并安全发送 客户ID, 客户机密 и 授权码.
- 授权服务器 检查数据并响应 访问令牌'om（访问令牌）。
- 现在 客户 可以使用 访问令牌 发送请求到 资源服务器 获取联系人列表。
客户端 ID 和密码
早在您允许 Terrible Pun of the Day 访问您的联系人之前，客户端和授权服务器就已经建立了工作关系。 授权服务器生成客户端 ID 和客户端密钥（有时称为 应用程序ID и 应用秘密) 并将它们发送给客户端，以便在 OAuth 中进行进一步的交互。
“- 你好！ 我想和你一起工作！ - 当然，没问题！ 这是您的客户 ID 和机密！”
顾名思义，Client Secret 必须保密，只有 Client 和 Authorization Server 知道。 毕竟，正是在他的帮助下，Authorization Server 才确认了 Client 的真实性。
但这还不是全部……欢迎 OpenID Connect！
OAuth 2.0 专为 授权书 - 提供从一个应用程序到另一个应用程序的数据和功能访问。 (OIDC) 是 OAuth 2.0 之上的一个薄层，它添加了登录帐户的用户的登录和个人资料详细信息。 登录会话的组织通常称为 验证 [验证]，以及有关登录系统的用户的信息（即关于 资源所有者'e), — 个人资料 [身份]. 如果授权服务器支持 OIDC，它有时被称为 个人资料提供者 [身份提供者]因为它提供 客户'有关于的信息 资源所有者'e.
OpenID Connect 允许您实现可以在多个应用程序中使用单个登录的场景 - 这种方法也称为 单点登录 （单点登录）。 例如，应用程序可能支持与 Facebook 或 Twitter 等社交网络的 SSO 集成，允许用户使用他们已经拥有并喜欢使用的帐户。
OpenID Connect 的流程（flow）看起来和 OAuth 的情况一样。 唯一不同的是，在初级请求中，使用的具体范围是 openid， - A 客户 最终变得像 访问令牌和 ID公链币.
就像在 OAuth 流程中一样， 访问令牌 在 OpenID Connect 中，这是一些不清楚的值 客户'在。 从角度来看 客户'A 访问令牌 表示随每个请求一起传递给的字符串 资源服务器'y，它确定令牌是否有效。 ID公链币 代表完全不同的东西。
ID Token 是一个 JWT
ID公链币 是一种特殊格式的字符串，称为 JSON Web Token 或 JWT （有时 JWT 令牌发音像“jots”）. 对于外部观察者来说，JWT 可能看起来像是难以理解的胡言乱语，但是 客户 可以从JWT中提取各种信息，比如ID、用户名、登录时间、有效期 ID公链币'a，存在干扰 JWT 的企图。 里面的数据 ID公链币'一个被称为 应用程序 [索赔].
对于 OIDC，还有一种标准方法 客户 可能会要求提供有关个人的其他信息 [身份] 从 授权服务器'a，例如，电子邮件地址使用 访问令牌.
了解有关 OAuth 和 OIDC 的更多信息
因此，我们简要回顾了 OAuth 和 OIDC 的工作原理。 准备好深入挖掘了吗？ 以下是可帮助您了解有关 OAuth 2.0 和 OpenID Connect 的更多信息的其他资源：
一如既往，请随时发表评论。 要了解我们的最新消息，请订阅 и 面向开发人员的 Okta！
译者PS
另请阅读我们的博客：
- «“;
- «“;
- «“;
- «“。
来源： habr.com