相关疑难解决方法(0)

localStorage,sessionStorage,session和cookies的技术优势和缺点是什么？我何时使用其中一个？

HTTP有HTTP Cookie.Cookie允许服务器跟踪用户状态,连接数,最后连接数等.

HTTP具有持久连接(Keep-Alive),其中可以从同一TCP连接发送多个请求.

我正在用支持它的浏览器(除了IE之外的任何人)用localStorage替换cookie .问题是site.com和www.site.com存储自己独立的localStorage对象.我相信www被认为是一个子域名(如果你问我,这是一个愚蠢的决定).如果用户最初在site.com上并决定输入www.site.com在下次访问时,她的所有个人数据都将无法访问.如何让所有"子域"与主域共享相同的localStorage？

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

我读到在使用JWT时,没有必要防止CRSF攻击,例如:" 因为你不依赖于cookie,所以你不需要防止跨站点请求 ".

但是,我不明白:如果我将令牌存储在localStorage中(正如我在同一网站的教程中所建议的那样),是什么阻止攻击者通过读取我的localStorage而不是我的cookie来伪造恶意请求？

由于它是在服务器端生成的,因此我不知道如何在客户端请求中使用令牌而不将其存储在客户端的某个位置.

我们在同一域但不同的子域中有两个独立的网站/应用程序。

例如

https://hello.website.com (Webapp 1)\nhttps://world.website.com (Webapp 2)\n

我们\xe2\x80\x99d 想要做的是在 Webapp 1 上登录用户，登录并单击 Webapp 1 中的按钮后，我们\xe2\x80\x99d 希望将用户重定向到 Webapp 2。但是，Webapp 2需要与当前存储在 Web 应用程序 1 的本地存储中的相同身份验证令牌。如何使本地存储内容可供 Web 应用程序 2 使用？

或者有更好的方法来做到这一点吗？

好吧,我花了几天时间寻找一个合适的解决方案,以便在使用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对)

在使用 IdP 通过 IdP 对其用户进行身份验证的 Web 应用程序中，oauth2用于实现用户权限（客户端和服务器端）的更标准/推荐选项是什么？

通过“用户权限”，我指的是用户在应用程序中允许或不允许执行的操作。
例如，假设应用程序有一个“管理”页面，用于管理应用程序的某些设置，仅允许特定用户进入。其中一些用户仅被允许查看当前设置，而其他用户也被允许更改设置（可能只有其中一些）。

据我所知，oauth2 中“范围”的概念可能用于实现这样的要求，例如，仅被允许查看“管理”页面app:admin:view的用户将具有范围，而可以此外，编辑设置也会有一个app:admin:some-setting:edit范围。
但是，在大多数大型身份提供者服务中，管理这些范围并将它们分配给用户的任务似乎是一项相当乏味的任务。

这会是一个很好的解决方案吗？如果是这样，是否有任何产品/服务与 oauth2 IdP 集成并帮助更轻松地管理权限及其分配给用户（例如，具有漂亮直观的 UI）？如果没有，是否有任何既定方法处理此类情况？