这个插件中的身份验证流程的架构很棒; 我理解安全问题。 尽管它可能禁用了此类功能的主要用例:Wordpress 作为无头 CMS。
无头 CMS 将要求用户通过username
和password
登录。 一旦用户拥有 JWT,他们就可以向受保护的资源发送经过身份验证的请求,在无头 CMS 环境中,要求用户生成 API 令牌将是禁止和违反直觉的。
安全性应通过 RBAC 权限、用户角色和职责来实现,这些权限规定了 API 中受保护的内容。 可以通过非常严格的 RBAC 默认值来缓解安全问题。 Wordpress 已经有一个很好的角色和责任框架。
为了解决实际的安全问题:
tokens
和长期refresh_tokens
(刷新令牌是可撤销的)因此这比分发可能丢失的无限寿命 API 令牌更安全。这种方法本质上是 oAuth2 "personal access"
令牌授予方案。 因此,我会质疑自定义令牌身份验证服务器方法的优点,例如这种正确的 oAuth2 标准实现? 如果安全是这里的主要关注点,那么这种方法实际上存在安全风险吗? 例如经过实战考验的 oAuth2 实现,例如php-league-oatuh-2
我看到当前身份验证流程application-to-application
身份验证的唯一可行用例? oAuth2 列出了多种授权流程方法来授予令牌。 一个是这种方法使用"personal access"
,另一个是我描述的"password access"
令牌。 完整的 oAuth2 实现将允许这两种情况以及更多...
我们相信,如果开发人员可以轻松访问诸如无状态 API 身份验证之类的东西,那么 WP-API 的采用以及 Wordpress 生态系统的现代化将会大大增强。
这些只是沉思,很乐意讨论和贡献!
做得好!
在 REST API 成为核心之前,我一直在构建(或尝试)原生应用程序。 (即:年)
最初,我的应用程序验证和上传/创建内容的唯一方法是使用 API 团队启动的“OAuth1.0a”插件。
我现在可以为 OAuth2.0 工作(同样,另一个需要安装额外插件的功能。不知道这是否会成为核心)
现在我们有了 JWT,它在如何连接我的应用程序方面提出了新问题。 自然,用户名/密码会更好,提供令牌。 (幸运的是,这个 JWT 的 'WP-API' 版本支持令牌刷新。另一个广泛使用的 JWT 插件不支持)
我无法相信大量失去的机会(和时间)正在过去,没有可靠的“无头”/移动实现“开箱即用”(核心)的身份验证。
我的移动应用程序需要它自己的插件来完成它的工作并支持大量与管理相关的事情和路由增强功能。 自定义块等。我宁愿不必让我的应用程序用户/客户必须下载并安装另一个“未完成”插件。
我只希望存在一个可靠(和“官方”)的解决方案。
我非常同意。 Wordpress 的定位是成为无头 cms 领域的领导者。 似乎核心团队在这方面取得了进展,但也许只是为 wordpress.com 的特定用例提供服务? 不确定。
为此,我们目前正在开发一个同构客户端。 连同反应钩子和提供者。 https://github.com/wp-headless/fetch。 也许我们将不得不编写自己的 JWT 身份验证插件。 我对它应该是什么样子的想法:
password
、 machine-to-machine
、 api-key
等。在这里,我坚持尝试通过 WP REST API 实现用户注册/身份验证系统,却发现 WP 团队正在重新发明轮子,发明一个新轮子。
最有用的评论
在 REST API 成为核心之前,我一直在构建(或尝试)原生应用程序。 (即:年)
最初,我的应用程序验证和上传/创建内容的唯一方法是使用 API 团队启动的“OAuth1.0a”插件。
我现在可以为 OAuth2.0 工作(同样,另一个需要安装额外插件的功能。不知道这是否会成为核心)
现在我们有了 JWT,它在如何连接我的应用程序方面提出了新问题。 自然,用户名/密码会更好,提供令牌。 (幸运的是,这个 JWT 的 'WP-API' 版本支持令牌刷新。另一个广泛使用的 JWT 插件不支持)
我无法相信大量失去的机会(和时间)正在过去,没有可靠的“无头”/移动实现“开箱即用”(核心)的身份验证。
我的移动应用程序需要它自己的插件来完成它的工作并支持大量与管理相关的事情和路由增强功能。 自定义块等。我宁愿不必让我的应用程序用户/客户必须下载并安装另一个“未完成”插件。
我只希望存在一个可靠(和“官方”)的解决方案。