注意事项 佩雷夫 :这篇很棒的Okta博客文章介绍了OAuth和OIDC(OpenID Connect)如何工作。 这种知识对于流行的Web应用程序的开发人员,系统管理员甚至“普通用户”将很有用,这些Web应用程序很可能还会与其他服务交换敏感数据。在互联网的石器时代,服务之间的共享信息很容易。 您只需将用户名和密码从一项服务提供给另一项服务,以便它输入您的帐户并接收所需的任何信息。
“提供您的银行帐户。” “我们保证,使用密码和金钱,一切都会好起来的。 老实说,这真是诚实!” *嘻嘻*恐怖! 任何人都不应要求用户与另一服务共享其用户名和密码,其
凭据 。 无法保证此服务背后的组织将确保数据安全,并且不会收集不必要的更多个人信息。 看起来似乎很疯狂,但是某些应用程序仍在使用这种做法!
如今,只有一种标准可以使一项服务安全地使用另一项数据。 不幸的是,这样的标准使用了大量的术语和术语,这使它们的理解变得复杂。 本材料的目的是用简单的插图说明它们的工作原理(您认为我的画像婴儿涂布吗?好吧!)。

顺便说一句,本指南还提供视频格式:
女士们,先生们,见面:OAuth 2.0
OAuth 2.0是一项安全标准,允许一个应用程序获得访问另一应用程序中信息的权限。 发出许可
(许可 )的步骤顺序通常称为
授权 ,甚至是
委托授权 。 使用此标准,您可以允许应用程序代表您读取数据或使用其他应用程序的功能,而无需告知您密码。 上课!
例如,假设您发现了一个名为“
每日糟糕的双关
”的网站,并决定在该站点上注册,以通过手机接收短信形式的双关语。 您真的很喜欢该网站,因此决定与所有朋友分享。 毕竟,像每个人一样的双关语对吗?
“今天的双关语没有成功:您听说过一个男人失去了他的左半身吗?” 现在他永远是对的!”(近似翻译,因为原文有其双关语-大约翻译。)显然,从联系人列表向每个人写信不是一种选择。 而且,如果您甚至有点像我,那么您将尽一切努力避免不必要的工作。 幸运的是,当天的双关语可以自己邀请所有朋友! 为此,您只需要授予他访问联系人电子邮件的权限-网站本身就会向他们发送邀请(OAuth驱动器)!
“每个人都喜欢双关语!” -已经登录? -想要与您的联系人列表共享“每日双关语”网站吗? -谢谢! 现在,我们每天都会向您认识的所有人发送提醒,直到时间结束! 您是最好的朋友!”- 选择您的电子邮件服务。
- 如有必要,请转到邮件站点并登录到您的帐户。
- 授予“每天糟糕的双关”权限以访问您的联系人。
- 返回每日糟糕的双关网站。
万一您改变主意,使用OAuth的应用程序还提供了一种撤消访问权限的方法。 决定不再希望与“每日恐怖”共享联系人后,您可以转到邮件站点,然后从授权应用程序列表中删除带有双关语的站点。
OAuth流
我们只是经历了通常称为OAuth
[flow] 流的过程 。 在我们的示例中,该流程包括可见步骤以及几个不可见步骤,其中两个服务就安全的信息交换达成了共识。 之前的“每日糟糕的双关”示例使用了最常见的OAuth 2.0流,称为
“授权码”流 。
在深入研究OAuth的细节之前,让我们先谈谈一些术语的含义:
- 资源所有者 :

这就是你! 您拥有自己的凭据,数据并管理可以使用您的帐户执行的所有操作。 - 客户 :

想要代表Resource Owner访问或执行某些操作的应用程序(例如,每日糟糕的双关服务)。 - 授权服务器 :

知道资源所有者并且其中资源所有者已经有一个帐户的应用程序。 - 资源服务器 :

客户端要代表Resource Owner使用的应用程序编程接口(API)或服务。 - 重定向URI :

授权服务器将资源所有者重定向到 “在授予客户端权限之后”重定向到的链接。 有时称为回调URL。 - 回应类型 :

客户期望接收的信息类型。 最常见的响应类型是代码,即客户希望收到授权代码 。 - 适用范围 :

这是客户端所需权限的详细说明,例如访问数据或执行某些操作。 - 同意书 :

授权服务器采用客户端请求的范围 ,并询问资源所有者是否准备好向客户端授予适当的权限。 - 客户编号 :

此ID用于标识授权服务器上的客户端 。 - 客户机密 :

这是仅客户端和授权服务器知道的密码。 它允许他们秘密地交换信息。 - 授权码 :

客户端提供给授权服务器以换取访问令牌的短期临时代码。 - 访问令牌 :

客户端将用于与资源服务器通信的密钥。 这是一种徽章或钥匙卡,可授予客户端代表您请求数据或在资源服务器上执行操作的权限。
注意 :有时授权服务器和资源服务器是同一台服务器。 但是,在某些情况下,这些服务器可能是不同的服务器,甚至不属于同一组织。 例如,授权服务器可以是资源服务器信任的第三方服务。
现在,我们已经熟悉了OAuth 2.0的基本概念,让我们回到示例中,仔细研究一下OAuth流中发生的情况。

- 您( 资源所有者 )希望授予“每日双关语”( 客户 )访问您的联系人的权限,以便他可以向所有朋友发送邀请。
- 客户端将浏览器重定向到“ 授权服务器”页面,并在请求中包括客户端ID , 重定向URI , 响应类型以及所需的一个或多个范围 (权限)。
- 如果有必要, 授权服务器会检查您的用户名和密码。
- 授权服务器显示“ 同意”表单,其中包含客户端请求的所有范围的列表。 您同意或拒绝。
- 授权服务器使用Redirect URI和Authorization Code将您重定向到客户端站点。
- 客户端直接与授权服务器通信(绕过资源所有者的浏览器),并安全地发送客户端ID , 客户端密码和授权代码 。
- 授权服务器验证数据并使用访问令牌进行响应。
- 客户端现在可以使用访问令牌将请求发送到资源服务器以获取联系人列表。
客户编号和机密
在您允许“一天中的可怕双关”访问您的联系人很久之前,客户端和授权服务器就建立了工作关系。 Authorization Server生成了客户端ID和客户端密钥(有时称为
App ID和
App Secret ),并将它们发送给客户端以在OAuth中进行进一步的交互。
“你好! 我想和你一起工作! -是的,没问题! 这是您的客户ID和机密!”该名称表明应将“客户端机密”保密,以便只有“客户端”和“授权服务器”才能知道。 确实,授权服务器在他的帮助下确认了客户的真实情况。
但这还不是全部...请欢迎OpenID Connect!
OAuth 2.0仅用于
授权 -提供从一个应用程序到另一个应用程序的数据和功能访问。
OpenID Connect (OIDC)是OAuth 2.0之上的薄层,可添加有关登录帐户的用户的用户名和配置文件的信息。 登录会话的组织通常称为
身份验证 ,有关登录用户的信息(即有关
资源所有者 )的信息称为
identity 。 如果授权服务器支持OIDC,则有时将
其称为
身份提供程序 ,因为它为
客户端提供了有关
资源所有者的信息 。
OpenID Connect允许您实现可以在许多应用程序中使用单一登录的方案-这种方法也称为
单一登录 (SSO)。 例如,应用程序可以支持与诸如Facebook或Twitter之类的社交网络的SSO集成,从而允许用户使用他们已经拥有并喜欢使用的帐户。

OpenID Connect流程看起来与OAuth相同。 唯一的区别是,在初始请求中,使用的特定范围是
openid
,并且
Client最终同时收到
Access Token和
ID Token 。

就像OAuth流中一样,OpenID Connect中的
访问令牌是
Client不理解的值。 从
客户端的角度来看,
访问令牌表示特定的字符串,该字符串与每个请求一起传输到
资源服务器 ,
资源服务器确定
资源令牌是否有效。
ID令牌是完全不同的。
ID令牌是JWT
ID令牌是一种特殊格式的字符串,称为JSON Web令牌或JWT
(有时JWT令牌发音为“ jots”) 。 对于外部观察者来说,JWT似乎难以理解,但是,
客户可以从JWT提取各种信息,例如ID,用户名,帐户登录时间,
ID令牌到期日期,并尝试干预JWT。
令牌ID中的数据称为
Claim 。

在OIDC的情况下,还有一种标准的方式,即
客户端可以从
授权服务器请求其他
身份信息,例如,使用
访问令牌的电子邮件地址。
了解有关OAuth和OIDC的更多信息。
因此,我们简要回顾了OAuth和OIDC的工作方式。 准备深入研究了吗? 以下是其他资源,可帮助您了解有关OAuth 2.0和OpenID Connect的更多信息:
与往常一样,请随时发表评论。 为了跟上我们的最新创新,请为
Twitter订阅Okta,为开发者订阅
YouTube !
译者的PS
另请参阅我们的博客: