• 赚钱入口【需求资源】限时招募流量主、渠道主,站长合作;【合作模式】CPS长期分成,一次推广永久有收益。主动打款,不扣量;

OAuth 2.0详解–每个软件工程师应了解的OAuth 2.0知识

JavaScript rin, seun 1年前 (2020-06-21) 164次浏览 0个评论

OAuth 2.0是用于授权的行业标准协议。

OAuth 2.0详解

当我在OAuth 2.0主页上阅读以上句子时,我觉得这是我应该给自己打电话给软件工程师的那种知识,因此我开始进行挖掘。我记得我有些害怕,因为我必须突破很多难以学习的知识,但是事实证明还不错,我决定分享我所学到的知识!

您将从本文中获得什么:

  • OAuth 2.0的工作方式
  • 应用程序如何获取访问令牌
  • SPA和Web服务器应用程序如何处理OAuth
  • 访问令牌的类型及其验证

OAuth 2.0详解--每个软件工程师应了解的OAuth 2.0知识

OAuth 2.0的工作方式

首先,如果您像我一样,正式的规范并不总是最好的地方来了解OAuth的工作原理,因为您可能马上就会被大量的信息淹没(因为这不是一个规范,而是很多他们)。要了解OAuth的工作原理,让我们提出问题。

让我们以一个应用程序为例,假设我们的用户拥有一个Google帐户,其中包含要从日历中获取的一些数据,而我们希望查看该用户的每日日程安排,但是在考虑安全性的情况下,我们如何可以向用户要求这些数据呢?这是OAuth发挥作用的关键时刻,但是重要的是:OAuth不会告诉应用程序您是谁,它只是使应用程序可以访问它所要求的数据

简单的答案是,通过提供访问令牌,该令牌使您的客户端应用程序可以从资源服务器获取所需的数据。我想描述一个比喻,它使我很了解这一点:

假设您在一家较大的公司工作,您必须使用门禁卡进入。该卡是在上班的第一天,由一位知道您是新员工的人以适当的权限提供给您的。在第一天之后,您使用这张卡进入公司,而没人再检查您的身份了,您只需将访问卡放到阅读器上,门就会打开。此外,你不能打开所有的门,但仅此一个,让你做你的日常工作任务。OAuth基于这种流程。

结论

  • 您将在第一天通过验证,并会收到一张每天均可使用的访问卡
  • 每个读者都会为您打开一扇门(如果已授予您进入该区域的权限
  • 读者不知道任何关于你的身份,那就是为读者唯一重要的事情是,如果你在你的手有效的准入证。

OAuth 2.0详解--每个软件工程师应了解的OAuth 2.0知识

应用程序如何获得访问令牌?

从应用程序的角度来看,目标是获取访问令牌,然后借助此令牌获取数据-那么应用程序如何获取访问令牌?

通过OAuth获取令牌的方式:

  • 授权代码流(Web应用程序,本机应用程序)
  • 设备流(AppleTV)
  • 密码(适用于第一方应用)
  • 客户凭证(机器对机器)

授权代码流是最常见的方法,因为它同时在Web和本机应用程序中使用。在我们可以回答它在OAuth中实际如何工作的问题之前,我们需要知道的另一件事是OAuth中存在哪种角色

OAuth角色:

  • 用户(资源所有者)*
  • 设备(用户代理)
  • 应用程序(客户端)
  • OAuth服务器(访问令牌来自的授权服务器)
  • API(资源服务器)

*括号中的名称是OAuth规范中使用的名称

一个正确的图表可能价值一千多个字:

OAuth 2.0详解--每个软件工程师应了解的OAuth 2.0知识

获取访问令牌
  1. 用户登录到应用程序;
  2. 应用程序请求用户访问某些数据(Google日历),并将用户重定向到OAuth服务器;
  3. 用户使用凭据登录到OAuth服务器;
  4. OAuth服务器返回一个临时代码,然后由应用程序将其交换为访问令牌;
  5. 用户向应用发送临时代码;
  6. 应用程序将代码交换为访问令牌。
  7. OAuth服务器返回该应用程序的访问令牌;
  8. 该应用程序使用访问令牌从资源服务器获取一些数据。
  9. 资源服务器将用户数据返回到应用程序。

题外话: 上图的应用程序徽标不是偶然出现的,这是我新创建的与朋友打赌的应用程序。我将其命名为 Betbitly,如果您感到好奇,请检查更多。

此访问令牌流可以分为两个通道:

🍎 前通道(红线)

数据是通过URL发送的,由于该请求/响应,用户/恶意软件可能会对其进行篡改。在这种情况下,有人看不到您添加访问令牌的人。双方都不知道数据是否未被篡改或从有害来源发送。有人可以沿途更改数据。

您可以想象这样一种情况:您向没有信箱的朋友发送了一封信,并且没有选择传递给所有者的选项,因此邮递员可能将这封信留在前门,因此直到朋友回家后,其他人可以得到这封信并对其进行更改。在这种情况下,您和您的朋友都无法百分百确定一个不请自来的人没有更改这封信。在这种情况下,为什么还要使用前置声道?

前通道是必需的,因为它是与用户通信以授权应用程序使用来自资源服务器的数据的自然接口,另一个示例可以是移动设备。

🍏 反向通道(绿线)

这是通信的安全部分,因为它是通过HTTPS从应用程序发送到服务器的(不能被篡改)。

与信件类似,可以选择将信件传递给所有者。

  • OAuth可以通过四种不同方式获取访问令牌
  • OAuth角色共有五种
  • 应用程序获取用户数据的方式可以分为两个渠道(前,后)

OAuth 2.0详解--每个软件工程师应了解的OAuth 2.0知识

深入探讨两种类型的客户!

在保密的应用程序可能性方面,我们可以将其再次划分为两种类型的客户端:

机密客户端(应用程序在服务器上运行)可以保持机密,
公共客户端( SPA或本机客户端)不能机密。

牢记这一划分,我将描述每种类型的请求的外观。这将是四个请求,两个用于授权,两个用于获取访问令牌数字表示架构上的数字)。

授权(前频道 🍎 

  1. 用户=> OAuth服务器(3)
  2. OAuth服务器=>用户(5)

获取访问令牌(反向通道 🍏 

  1. 应用程序=> OAuth服务器(6)
  2. OAuth服务器=>应用程序(7)

授权(前频道 🍎 

这里值得一提的是Scope。Scope保证应用程序只能访问(用户登录OAuth服务器)登录期间请求的数据。用户应始终应被授予了哪些数据访问权限。

OAuth 2.0详解--每个软件工程师应了解的OAuth 2.0知识

如果用户允许应用程序访问资源,则OAuth服务器将使用代码进行响应,然后由应用程序将其交换为访问令牌:

获取访问令牌(反向通道 🍏 

这种应用程序不能完全维护客户端的秘密,因为它完全在浏览器中运行,因此,为了保留上面介绍的授权代码流,必须在每个请求上生成秘密,这称为PKCE,代表代码交换的证明密钥,因此为了实现此目标,我们不必更改客户端秘密,而是发送每次获取访问令牌流开始时生成的PKCE,而是要通过添加以下两种方式来更改以前的Web服务器授权请求(auth-req.web-server.js):

  • 代码验证程序(随机字符串,长度为43–128个字符)
  • 代码质询(代码验证程序的URL安全base64编码的SHA256哈希)

授权(前频道 🍎 

获取访问令牌(反向通道 🍏 

移动应用程序也无法生成秘密,因此我们必须在此处使用PKCE秘密,以获取更多信息,我建议您访问aaronparecki网站。

  • 保密和公开两种类型的客户;
  • 机密客户端可以保守秘密(Web服务器应用程序);
  • 公开客户不能保守秘密(SPA);
  • PKCE,而不是公共客户端中的客户端机密。

访问令牌

参考令牌:

  • 经常存储在数据库中
  • 允许您使用任何标准数据库数据执行的每种操作,例如,显示活动令牌的列表
  • 可以轻松撤消(只需从数据库中删除)
  • 由于需要存储所有令牌,因此可用于较小的应用程序。

自编码令牌:

  • 数据存在令牌本身(JWT)中
  • 不必存储
  • 分离关注点,API不必具有存储访问令牌
  • 在API上无效,不能像参考令牌中那样通过DB / HTTP查找
  • 无法获取所有活动令牌的列表
  • 更适合更大的应用

访问令牌验证

授予访问令牌后,必须对其进行验证。它可能由于到期或吊销的两个原因而变得无效。

令牌过期与过期时间有关,令牌过期是从OAuth服务器返回的属性之一,当应用程序交换从用户那里收到的用于交换令牌的代码时,其余数据也会随之过期。

假设有一个访问令牌过期设置为1小时,但我们的应用程序会话比这更长的时间,例如4小时。为了提供最佳的用户体验,我们不想让用户在一个会话中登录4次-为解决此问题,我们从OAuth服务器收到了刷新令牌以及访问令牌,该令牌允许应用程序获取新的访问令牌后台的用户。访问令牌和刷新令牌之间的主要区别是生命周期,访问令牌的寿命很短,因此存储它不需要像参考令牌这样的安全性,因为它的生命周期很长,因为如果攻击者偷窃它,后果将更糟。

撤销非常简单,它在用户告诉OAuth服务器该令牌不再有效时发生。

撤销令牌发行

注意:请注意以下事实:如果您仅执行本地验证,并且访问令牌的到期时间为4h,并且1h用户撤消应用程序以使用数据,则本地验证仍将通过,因为它对撤消操作一无所知,但是如果应用程序询问OAuth服务器,则该令牌将无效,因此在最坏的情况下,您可以在3h内拥有一个无效的令牌,但在本地仍然有效,因为您应该处理本地验证每个受保护的HTTP请求,然后在您的应用程序中确定对哪些数据如此敏感,应该向OAuth服务器发出另一个请求,以检查令牌是否尚未撤消。

  • 两种类型的令牌参考和自编码
  • 令牌可以过期或被撤销
  • 在处理对安全敏感的操作之前,请始终询问OAuth服务器访问令牌是否仍然有效

OAuth 2.0详解--每个软件工程师应了解的OAuth 2.0知识

喜欢 (0)

您必须 登录 才能发表评论!