相关疑难解决方法(0)

注意:我在这个问题上有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等

好吧,我花了几天时间寻找一个合适的解决方案,以便在使用SPA时如何正确地验证用户身份.

1. 我有自己的网站.
2. 我有自己的API.
3. 我有自己的单页应用程序.
4. 我有自己的用户数据库.

目标:我需要通过提供用户名和密码来获取access_token.

我查看了OAuth2 Implicit Grant,但它要求用户在成功验证后批准/拒绝应用程序.它在我的情况下不起作用,因为我拥有应用程序和API.

我查看了OAuth2密码授予,这是不完美的,因为我需要公开client_id/client_secret.

我正在考虑OAuth2的原因是因为API最终会公开.

有这样做的标准方法吗？我目前的选择:

1. 忘记OAuth2并在用户POST用户名/密码时手动生成access_token(在这种情况下,当API上线时我必须引入OAuth2)
2. 使用OAuth2密码授予并在服务器上注入client_id/client_secret,这样只是为了保持客户端应用程序非常简单(也避免所有这些dev/staging/prod client_id/client_secret对)