Laravel 5.6 - 用于自助API的Passport JWT httponly cookie SPA身份验证？

Question

注意:我在这个问题上有4个赏金,但下面没有提出的答案是这个问题所需要的答案.所需的一切都在下面的Update 3中,只是寻找要实现的Laravel代码.

---

更新3:此流程图正是我想要完成的流程,下面的所有内容都是原始问题以及一些较旧的更新.该流程图总结了所需的一切.

下面的流程图中的绿色部分是我知道如何做的部分.红色部分及其旁注是我正在寻找帮助完成使用Laravel代码.

---

我已经做了很多研究,但是当使用Laravel和JWT httponly cookie进行自我消费的API时,信息总是很短而且不完整(大多数在线教程只显示JWT存储在本地存储中,这不是很安全).看起来像包含JWT by Passport的httponly cookie应该用于识别Javascript端的用户,当每次请求发送到服务器以验证用户是否是他们所说的用户时.

还有一些额外的东西需要全面了解如何使这个设置工作,我没有在一个教程中遇到这个包括:

1. Laravel Passport(不是tymon auth)生成加密的JWT并将其作为httponly cookie发送,作为从JS端登录后的响应.使用什么中间件？如果刷新令牌添加更多安全性,如何实现？
2. JavaScript(例如axios)api伪代码,用于调用auth端点,如何将httponly cookie传递给后端,以及后端验证令牌是如何有效的.
3. 如果从多个设备登录单个帐户,那么设备被盗,如何撤销所有authed用户设备的访问权限(假设用户从他们可以控制的登录设备更改密码)？
4. 什么会登录/注册,注销,更改密码,忘记密码控制器方法通常看起来像处理令牌的创建/验证/撤销？
5. CSRF令牌集成.

我希望这个问题的答案可以作为一个易于遵循的指南,为未来的读者和那些正在努力寻找一个自我消费API的上述观点的答案.

更新1:

1. 请注意我尝试过CreateFreshApiToken之前的功能,但是在撤销用户令牌时这不起作用(上面的第3点和第4点).这是基于此评论的核心laravel开发商,谈论时CreateFreshApiToken中间件:

由此中间件创建的JWT令牌不会存储在任何位置.它们不能被撤销或"不存在".它们只是为您的api调用提供了一种通过laravel_token cookie进行authed调用的方法.它与访问令牌无关.另外:您通常不会在发布它们的同一个应用程序上使用客户发出的令牌.您可以在第一方或第三方应用中使用它们.使用中间件或客户端发出的令牌,但不能同时使用两者.

所以似乎能够迎合第3点和第4点来撤销令牌,如果使用CreateFreshApiToken中间件则不可能这样做.

2. 在客户端,Authorization: Bearer <token>处理安全的httpOnly cookie 似乎不是一种方法.我认为请求/响应应该包含安全的httpOnly cookie作为请求/响应头,像这样基于laravel文档:

使用此身份验证方法时,默认的Laravel JavaScript脚手架指示Axios始终发送X-CSRF-TOKEN和X-Requested-With标头.

headerswindow.axios.defaults.headers.common = {
    'X-Requested-With': 'XMLHttpRequest',
    'X-CSRF-TOKEN': (csrf_token goes here)
};

这也是我寻找涵盖上述所有要点的解决方案的原因.道歉,我使用的是Laravel 5.6而不是5.5.

更新2:

似乎密码授予/刷新令牌授权组合是要走的路.使用密码授予/刷新令牌授权组合寻找易于遵循的实施指南.

密码授予: 此授权适用于与我们信任的客户交易,例如我们自己网站的移动应用.在这种情况下,客户端将用户的登录凭据发送到授权服务器,服务器直接发出访问令牌.

刷新令牌授权: 当服务器发出访问令牌时,它还会为访问令牌设置到期时间.当我们想要在访问令牌过期时刷新访问令牌时,使用刷新令牌授予.在这种情况下,授权服务器将在发出访问令牌时发送刷新令牌,该令牌可用于请求新的访问令牌.

我正在寻找一个易于实现,直接,全面的答案,使用密码授予/刷新令牌授权组合,涵盖上述原始5点的所有部分与httpOnly安全cookie,创建/撤销/刷新令牌,登录cookie创建,注销cookie撤销,控制器方法,CSRF等

Answer 1

Laravel Passport JWT

1. 要使用此功能,您需要禁用cookie序列化.Laravel 5.5存在cookie值序列化/反序列化的问题.你可以在这里阅读更多相关信息(https://laravel.com/docs/5.5/upgrade)

2. 确保这一点

   • 你有<meta name="csrf-token" content="{{ csrf_token() }}">刀片模板头

   • axios设置为在每个请求上使用csrf_token.

你应该有这样的东西 resources/assets/js/bootstrap.js

window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';
let token = document.head.querySelector('meta[name="csrf-token"]');

if (token) {
  window.axios.defaults.headers.common['X-CSRF-TOKEN'] = token.content;
} else {
  console.error('CSRF token not found: https://laravel.com/docs/csrf#csrf-x-csrf-token');
}

3. 这里解释了安装auth路由(https://laravel.com/docs/5.5/authentication)
4. 这里解释了安装护照(https://laravel.com/docs/5.5/passport).

重要的部分是:

• 将Laravel\Passport\HasApiTokens特征添加到User模型中
• 在您driver的api身份中设置身份验证后卫的选项passportconfig/auth.php
• 将\Laravel\Passport\Http\Middleware\CreateFreshApiToken::class,中间件添加到您的web中间件组中app/Http/Kernel.php

请注意,您可能会跳过迁移和创建客户端.

5. 发送POST请求以/login传递您的凭据.您可以提交AJAX请求或普通表单.

如果登录请求是AJAX(使用axios),响应数据将是HTML,但您感兴趣的是状态代码.

axios.get(
  '/login, 
  {
    email: 'user@email.com',
    password: 'secret',
  },
  {
    headers: {
      'Accept': 'application/json', // set this header to get json validation errors.
    },
  },
).then(response => {
  if (response.status === 200) {
      // the cookie was set in browser
      // the response.data will be HTML string but I don't think you are interested in that
    }
    // do something in this case
}).catch(error => {
  if (error.response.status === 422) {
    // error.response.data is an object containing validation errors
  }
  // do something in this case
});

登录时,服务器通过提供的凭据查找用户,根据用户信息(id,email ...)生成令牌(此令牌不保存在任何地方),然后服务器返回带有加密cookie的响应,该cookie包含生成的令牌.

6. 对受保护的路由进行API调用.

假设你有一条受保护的路线

Route::get('protected', 'SomeController@protected')->middleware('auth:api');

您可以正常使用axios进行ajax调用.Cookie会自动设置.

axios.get('/api/protected')
  .then(response => {
    // do something with the response
  }).catch(error => {
    // do something with this case of error
  });

当服务器收到呼叫时,解密请求laravel_cookie并获取用户信息(例如:id,email ...)然后用该用户信息进行数据库查找以检查用户是否存在.如果找到用户,则授权用户访问所请求的资源.否则返回401.

使JWT令牌无效.当你提到评论时,没有必要担心这个,因为这个令牌没有保存在服务器上的任何地方.

更新

关于第3点,Laravel 5.6 Auth有一种新方法logoutOtherDevices.您可以从这里了解更多信息(https://laracasts.com/series/whats-new-in-laravel-5-6/episodes/7),因为文档非常清晰.

如果您无法更新Laravel版本,可以查看5.6中的完成情况,并为5.5构建自己的实现

你问题的第4点.看看中找到的控制器app/Http/Controllers/Auth.

关于access_tokens和refresh_tokens,这是一种完全不同且更复杂的方法.你可以在网上找到很多教程,解释如何做到这一点.

我希望它有所帮助.

PS.祝新年快乐!!:)

Answer 2

• Laravel Passport是PHP League的OAuth服务器的一个实现
• 密码授予类型可用于用户名+密码验证
• 请记住通过在代理中发出身份验证请求来隐藏您的客户端凭据
• 将刷新令牌保存在HttpOnly cookie中,以最大限度地降低XSS攻击的风险

您可以在此处查看更多信息

http://esbenp.github.io/2017/03/19/modern-rest-api-laravel-part-4/

Answer 3

我也在我的项目中实施了Laravel护照,我想我已经涵盖了你在问题中提到的大部分要点.

1. 我使用密码授予来生成访问令牌和刷新令牌.您可以按照以下步骤设置护照并实施护照授予.在您的登录方法中,您必须验证用户凭据并生成令牌并将cookie(将cookie附加到响应)附加到响应.如果你需要我可以给你一些例子.
2. 我为CORS添加了两个中间件(处理传入的请求头)并检查传入访问令牌是否有效,如果无效则从存储的刷新令牌(刷新令牌)生成访问令牌.我可以告诉你这个例子.
3. 登录后,来自客户端的所有请求都应包含Authorization标头(Authorization: Bearer <token>).

如果您对以上几点有所了解,请告诉我.

Answer 4

我将尝试以一种通用的方式回答这个问题，以便该答案适用于各种框架，实现和语言，因为所有问题的答案都可以从通用协议或算法规范中得出。

我应该使用哪种OAuth 2.0授权类型？

这是要决定的第一件事。对于SPA，两个可能的选择是：

1. 授权码授予（推荐，如果客户端机密存储在服务器端，则建议使用）
2. 资源所有者密码凭证授予

我没有提及隐式授予类型作为选项的原因是：

1. 通过提供客户端密码和授权代码的客户端身份验证步骤丢失了。安全性降低
2. 访问令牌将作为URL片段发送回（以便令牌不会发送到服务器），它将继续保留在浏览器历史记录中
3. 如果发生XSS攻击，则恶意脚本可以很好地将令牌发送到远程服务器，以控制攻击者

（“客户端凭据”授予类型不在此讨论范围之内，因为在客户端不代表用户执行操作时将使用它。例如，批处理作业）

对于授权码授予类型，授权服务器通常是与资源服务器不同的服务器。最好将授权服务器分开放置，并将其用作组织内所有SPA的通用授权服务器。这始终是推荐的解决方案。

此处（在授权码授予类型中）流程如下所示：

1. 用户单击SPA登录页面上的登录按钮
2. 用户将被重定向到授权服务器登录页面。URL查询参数中提供了客户端ID
3. 用户输入他/她的凭据，然后单击登录按钮。用户名和密码将使用HTTP POST发送到授权服务器。凭据应在请求正文或标头中发送，而不应在URL中发送（因为URL已记录在浏览器历史记录和应用程序服务器中）。此外，适当的缓存HTTP头应设置，使凭据不缓存：Cache-Control: no-cache, no-store，Pragma: no-cache，Expires: 0
4. 授权服务器根据用户数据库（例如LDAP服务器）对用户进行身份验证，其中用户名和用户密码的哈希（哈希算法（如Argon2，PBKDF2，Bcrypt或Scrypt）与随机盐一起存储）
5. 成功认证后，授权服务器将根据URL查询参数中提供的客户端ID从其数据库检索重定向URL。重定向URL是资源服务器URL
6. 然后，将使用URL查询参数中的授权代码将用户重定向到资源服务器端点。
7. 然后，资源服务器将向授权服务器发出HTTP POST请求以获取访问令牌。授权代码，客户端ID，客户端机密应放在请求正文中。（应使用上述适当的缓存头）
8. 授权服务器将在响应正文或标头中返回访问令牌和刷新令牌（具有如上所述的适当的缓存标头）
9. 现在，资源服务器将通过设置适当的cookie（将在下面详细说明）将用户（HTTP响应代码302）重定向到SPA URL。

另一方面，对于资源所有者密码凭证授予类型，授权服务器和资源服务器相同。它很容易实现，并且在适合需求和实现时间表的情况下也可以使用。

另请参阅我的答案在这这里对资源所有者授予类型的进一步细节。

在这里可能需要注意的重要一点是，在SPA中，只有在调用适当的服务后才能启用所有受保护的路由，以确保请求中存在有效的令牌。同样，受保护的API还应该具有适当的过滤器，以验证访问令牌。

为什么我不应该将令牌存储在浏览器的本地存储或会话存储中？

许多SPA确实在浏览器的本地存储或会话存储中存储访问和/或刷新令牌。我认为我们不应该将令牌存储在这些浏览器存储中的原因是：

1. 如果发生XSS，则恶意脚本可以轻松地从那里读取令牌并将其发送到远程服务器。从此以后，远程服务器或攻击者在模拟受害用户方面将没有问题。

2. 本地存储和会话存储未在子域之间共享。因此，如果我们有两个运行在不同子域上的SPA，则我们将无法获得SSO功能，因为一个应用程序存储的令牌对于组织内的另一个应用程序将不可用

但是，如果令牌仍存储在任何这些浏览器存储中，则必须包括正确的指纹。指纹是加密强度高的随机字节串。原始字符串的Base64编码字符串将被存储在HttpOnly，Secure，SameSite的cookie名称前缀__Secure-。Domain和Path属性的正确值。字符串的SHA256哈希也将在JWT声明中传递。因此，即使XSS攻击将JWT访问令牌发送到攻击者控制的远程服务器，它也无法发送cookie中的原始字符串，因此服务器可以基于cookie的缺失拒绝请求。此外，可以通过使用适当的content-security-policy响应头来进一步缓解XSS和脚本注入。

注意：

1. SameSite=strict确保给定的cookie不伴随来自其他站点（AJAX或通过以下超链接）的请求。简而言之-允许来自与目标站点具有相同“可注册域”的站点的任何请求。例如，如果“ http://www.example.com ”是站点的名称，则可注册域是“ example.com”。有关更多详细信息，请参见参考编号。以下最后一节中的3。因此，它提供了针对CSRF的保护。但是，这也意味着，如果给定的URL是论坛，则经过身份验证的用户将无法访问该链接。如果那是对应用程序的严重限制，SameSite=lax可以使用，只要HTTP方法是安全的，它将允许跨站点请求。GET，HEAD，OPTIONS和TRACE。由于CSRF基于不安全的方法（例如POST，PUT，DELETE），因此lax仍然可以防止CSRF

2. 为了允许cookie在所有请求中传递到“ example.com”的任何子域，该cookie的domain属性应设置为“ example.com”

为什么要在Cookie中存储访问令牌和/或刷新令牌？

1. 将令牌存储在cookie中时，我们可以将cookie设置为secure和httpOnly。因此，如果发生XSS，则恶意脚本无法读取它们并将其发送到远程服务器。XSS仍然可以从用户的浏览器中模拟用户，但是如果浏览器已关闭，则脚本不会造成进一步的损害。secure标志可确保无法通过不安全的连接发送令牌-SSL / TLS是强制性的
2. domain=example.com例如，将cookie中的根域设置为，可确保可在所有子域中访问cookie。因此，组织内的不同应用和服务器可以使用相同的令牌。只需登录一次

如何验证令牌？

令牌通常是JWT令牌。通常，令牌的内容不是秘密的。因此，它们通常不被加密。如果需要加密（可能是因为令牌中还传递了一些敏感信息），则有一个单独的规范JWE​​。即使不需要加密，我们也需要确保令牌的完整性。任何人（用户或攻击者）都不能修改令牌。如果它们这样做，则服务器应该能够检测到该情况并拒绝所有带有伪造令牌的请求。为确保此完整性，使用诸如HmacSHA256之类的算法对JWT令牌进行数字签名。为了生成此签名，需要一个秘密密钥。授权服务器将拥有并保护机密。每当调用授权服务器api来验证令牌时，授权服务器将根据传递的令牌重新计算HMAC。如果它与输入的HMAC不匹配，则返回否定响应。JWT令牌以Base64编码格式返回或存储。

但是，对于资源服务器上的每个API调用，都不会涉及授权服务器来验证令牌。资源服务器可以缓存授权服务器发出的令牌。资源服务器可以使用内存中的数据网格（即Redis），或者，如果不能将所有内容存储在RAM中，则可以使用基于LSM的DB（带有Level DB的Viz Riak）来存储令牌。

对于每个API调用，资源服务器都会检查其缓存。

1. 如果高速缓存中不存在访问令牌，则API应该返回适​​当的响应消息和401响应代码，以便SPA可以将用户重定向到适当的页面，在该页面上将请求用户重新登录

2. 如果访问令牌有效但已过期（请注意，JWT令牌通常包含用户名和有效期等），则API应该返回适​​当的响应消息和401响应代码，以便SPA可以调用适当的资源服务器API来使用刷新令牌（带有适当的缓存头）更新访问令牌。然后，服务器将使用访问令牌，刷新令牌和客户端机密调用授权服务器，授权服务器可以返回新的访问和刷新令牌，这些令牌最终向下流到SPA（带有适当的缓存头）。然后，客户端需要重试原始请求。所有这些将由系统处理，而无需用户干预。可以创建一个单独的cookie，以存储与访问令牌类似的刷新令牌，但具有适当的值Path 属性，以便刷新令牌不会随每个请求一起出现，而仅在续订请求中可用

3. 如果刷新令牌无效或过期，则API应该返回适​​当的响应消息和401响应代码，以便SPA可以将用户重定向到适当的页面，在该页面上将要求用户重新登录

为什么我们需要两个令牌-访问令牌和刷新令牌？

1. 访问令牌通常具有较短的有效期，例如30分钟。刷新令牌通常具有较长的有效期，例如6个月。如果访问令牌受到某种程度的破坏，则攻击者只有在访问令牌有效的情况下才能模拟受害者用户。由于攻击者没有客户端密码，因此无法向授权服务器请求新的访问令牌。但是，攻击者可以请求资源服务器进行令牌续订（如上述设置那样，续订请求正在通过资源服务器，以避免将客户端机密存储在浏览器中），但是鉴于采取了其他步骤，这种可能性不大，而且服务器可以根据IP地址采取其他保护措施。

2. 如果访问令牌的有效期很短，则如果需要的话，可以帮助授权服务器撤消从客户端发出的令牌。授权服务器还可以维护已发行令牌的缓存。然后，系统管理员可以根据需要将某些用户的令牌标记为已撤消。在访问令牌到期时，当资源服务器将转到授权服务器时，将强制用户再次登录。

那CSRF呢？

1. 为了保护用户免受CSRF的侵害，我们可以遵循Angular之类的框架中所遵循的方法（如Angular HttpClient 文档中所述）服务器必须发送一个非HttpOnly cookie（换句话说，是一个可读cookie），其中包含该特定会话的唯一不可预测的值。它应该是加密强度高的随机值。然后，客户端将始终读取cookie并在自定义HTTP标头中发送值（不应该具有任何状态更改逻辑的GET＆HEAD请求除外。请注意，由于相同的原始策略，CSRF无法从目标Web应用程序读取任何内容）这样服务器就可以从标题和cookie中验证该值。由于跨域表单无法读取Cookie或设置自定义标头，因此在CSRF请求的情况下，自定义标头值将丢失，服务器将能够检测到攻击

2. 为了防止应用程序登录CSRF，请始终检查referer标头并仅在referer受信任的域时才接受请求。如果referer标头不存在或域不在白名单中，则只需拒绝该请求即可。使用SSL / TLS时referrer通常会出现。登陆页面（主要是信息性的，不包含登录表单或任何受保护的内容，可能会有些松懈？并允许带有缺少referer标题的请求

3. TRACE应该在服务器中阻止HTTP方法，因为它可以用于读取httpOnlyCookie

4. 另外，设置标题 Strict-Transport-Security: max-age=<expire-time>; includeSubDomains吗？以仅允许安全连接以防止任何中间人覆盖子域中的CSRF cookie

5. 此外，SameSite应使用上述设置

最后，所有通信都必须使用SSL / TLS-从今天开始，低于1.1的TLS版本不兼容PCI / DSS。应使用正确的密码套件来确保前向保密性和经过身份验证的加密。另外，一旦用户明确单击“注销”，访问和刷新令牌应被列入黑名单，以防止任何可能的令牌滥用。

参考文献

1. RFC 6749-OAuth2.0
2. OWASP JWT速查表
3. SameSite Cookie IETF草案
4. Cookie前缀
5. RFC 6265-Cookie