OAuth和OpenID Connect图解指南

在 Internet 的“石器时代”，在服务之间共享信息很容易。您只需将一项服务的用户名和密码提供给另一项服务，这样他们就可以登录您的帐户并获取他们想要的任何信息！

哎呀！您绝不应该被要求将您的用户名和密码（即您的凭据）共享给另一个服务。没有任何保证可以确保一个组织会妥善保管您的凭据，或者保证其服务不会访问比必要更多的您的个人信息。这听起来可能有些疯狂，但确实有些应用仍然试图通过这种方式蒙混过关！

今天，我们有一个商定的标准，可以安全地允许一个服务访问另一个服务的数据。不幸的是，这些标准使用了大量的行话和术语，这使得它们更难理解。本文的目的是使用简化的插图来解释这些标准是如何工作的。

你可以把这篇文章看作是有史以来最糟糕的儿童读物。别客气。

女士们，先生们，推出 OAuth 2.0

OAuth 2.0 是一种安全标准，您可以授予一个应用程序访问另一个应用程序中的数据的权限。授予权限或同意的步骤通常称为授权，甚至称为委托授权。您授权一个应用程序访问您的数据，或代表您使用另一个应用程序中的功能，而无需向它们提供您的密码。甜！

举个例子，假设你发现了一个名为“每日糟糕双关语”的网站，并注册了一个账户，让它每天向你的手机发送一条糟糕的双关语笑话作为短信。你非常喜欢它，想要与你曾在网上遇到过的每一个人分享这个网站。谁不想每天都读一个糟糕的双关语呢，对吧？

而且，如果你像我一样，你会想尽一切办法避免任何像是工作的事情。幸运的是，“每日糟糕双关语”有一个邀请朋友的功能！您可以授予“Terrible Pun of the Day”对您的电子邮件联系人的访问权限并为您发送电子邮件！OAuth 取胜！

1. 选择您的电子邮件提供商
2. 重定向到您的电子邮件提供商并在需要时登录
3. 授予“Terrible Pun of the Day”访问您的联系人的权限
4. 重定向回 “Terrible Pun of the Day”

如果您改变主意，使用 OAuth 授予访问权限的应用程序也提供了一种撤销访问权限的方法。如果您稍后决定不再共享您的联系人，您可以转到您的电子邮件提供商并删除“Terrible Pun of the Day”作为授权应用程序。

让 OAuth 流动

您刚刚逐步完成了通常所说的 OAuth 流。此示例中的 OAuth 流由授予同意的可见步骤以及一些不可见的步骤组成，其中两项服务就交换信息的安全方式达成一致。前面的“Terrible Pun of the Day”示例使用了最常见的 OAuth 2.0 流程，称为“授权代码”流程。

在我们深入了解 OAuth 正在做什么的更多详细信息之前，让我们映射一些 OAuth 术语。

	资源所有者：您！您是您的身份、数据以及可对您的账户执行的任何操作的所有者。
	客户端：想要代表资源所有者访问数据或执行操作的应用程序（例如“Terrible Pun of the Day”）。
	授权服务器：知道资源所有者的应用程序，其中资源所有者已经有一个帐户。
	资源服务器：客户端希望代表资源所有者使用的应用程序编程接口 （API） 或服务。
	重定向 URI：授权服务器在向客户端授予权限后将资源所有者重定向回的 URL。这有时称为 “Callback URL”。
	响应类型：客户端希望接收的信息类型。最常见的响应类型是 ，其中 Client 需要 Authorization Code。code
	范围：这些是客户端所需的精细权限，例如访问数据或执行操作。
	同意：授权服务器采用客户端请求的范围，并与资源所有者验证他们是否要授予客户端权限。
	客户端 ID：此 ID 用于标识具有授权服务器的客户端。
	客户端密钥：这是只有客户端和授权服务器知道的密钥密码。这使他们能够在幕后安全地私下共享信息。
	授权码：客户端提供给授权服务器以换取访问令牌的短期临时代码。
	Access Token：客户端将用于与 Resource Server 通信的密钥。这类似于徽章或密钥卡，授予客户端代表您请求数据或向 Resource Server 执行操作的权限。

注意：有时 “Authorization Server” 和 “Resource Server” 是同一服务器。但是，在某些情况下，它们不会是同一服务器，甚至不是同一组织的一部分。例如，“Authorization Server”可能是“Resource Server”信任的第三方服务。

现在我们已经掌握了一些 OAuth 2.0 词汇表，让我们重新访问该示例，仔细看看整个 OAuth 流程中发生了什么。

1. 您（资源所有者）希望允许 “Terrible Pun of the Day”（客户）访问您的联系人，以便他们可以向您的所有朋友发送邀请。
2. 客户端将您的浏览器重定向到授权服务器，并在请求中包含客户端 ID、重定向 URI、响应类型以及它所需的一个或多个范围。
3. Authorization Server 将验证您的身份，并在必要时提示登录。
4. Authorization Server 根据客户端请求的 Scope 为您提供同意表单。您授予 （或拒绝） 权限。
5. 授权服务器使用重定向 URI 和授权代码重定向回客户端。
6. 客户端直接联系授权服务器（不使用资源所有者的浏览器）并安全地发送其客户端 ID、客户端密钥和授权码。
7. Authorization Server 验证数据并使用 Access Token 进行响应。
8. 客户端现在可以使用 Access Token 向 Resource Server 发送联系人的请求。

客户端 ID 和密钥

在您允许“每日糟糕双关语”访问您的联系人之前很久，客户端和授权服务器就已经建立了一种工作关系。授权服务器生成了一个客户端ID和客户端密钥（有时也称为应用ID和应用密钥），并将它们提供给了客户端，以便在未来的所有OAuth交换中使用。

顾名思义，Client Secret 必须保密，以便只有 Client 和 Authorization Server 知道它是什么。这就是 Authorization Server 验证 Client 端的方式。

这还不是全部，伙计们……请欢迎 OpenID Connect

OAuth 2.0 仅用于授权，即允许一个应用访问另一个应用的数据和功能。OpenID Connect (OIDC) 是在 OAuth 2.0 基础上添加的一个薄层，它提供了关于登录用户的登录信息和个人资料信息。建立登录会话通常被称为身份验证，而关于登录用户（即资源所有者）的信息则被称为身份。当授权服务器支持 OIDC 时，它有时被称为身份提供者，因为它向客户端提供关于资源所有者的信息。

OpenID Connect 支持跨多个应用程序使用一个登录名的场景，也称为单点登录 （SSO）。例如，应用程序可以支持社交网络服务（如 Facebook 或 Twitter）的 SSO，以便用户可以选择利用他们已经拥有并舒适使用的登录名。

OpenID Connect 流看起来与 OAuth 相同。唯一的区别是，在初始请求中，使用了特定的范围 ，而在最终交换中，Client 同时接收 Access Token 和 ID Token。openid

与 OAuth 流程一样，OpenID Connect 访问令牌是客户端无法理解的值。就 Client 而言，Access Token 只是一串随任何请求传递给 Resource Server 的乱码，Resource Server 知道 Token 是否有效。但是，ID 令牌非常不同。

记下这个：ID 令牌是 JWT

JWT 有时会被读作“jots”。JWT 对你和我来说可能看起来像是一堆乱码，但客户端可以从 JWT 中提取嵌入的信息，如你的 ID、姓名、登录时间、ID Token 的过期时间，以及是否有任何尝试篡改 JWT 的行为。ID 令牌中的数据称为声明。

借助 OIDC，客户端还可以通过一种标准方式使用访问令牌从授权服务器请求其他身份信息，例如其电子邮件地址。

原文来源：https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc