このプラグインの認証フローのアーキテクチャは素晴らしいです。 セキュリティ上の懸念を理解しています。 それはおそらくそのような機能の主なユースケースを無効にしますが：ヘッドレスCMSとしてのWordpress。
ヘッドレスCMS認証を無効にします
ヘッドレスCMSでは、ユーザーはusernameとpasswordを介してログインする必要があります。 ユーザーがJWTを取得すると、保護されたリソースに認証されたリクエストを送信できます。ヘッドレスCMS環境では、ユーザーにAPIトークンの生成を求めることは法外で直感に反します。
セキュリティは、APIで保護されるものを指示するRBAC特権、ユーザーロール、および責任を通じて実装する必要があります。 セキュリティ上の懸念は、RBACの非常に厳密なデフォルトによって軽減できます。 すでにWordpressには素晴らしい役割と責任のフレームワークがあります。
実際のセキュリティ上の懸念に対処するには：
- 寿命の長いトークン？ それらを短命のトークンにします。
- 寿命の長いトークンが盗まれる可能性があるという懸念はありますか？ APIトークン、null引数も同様です。
- JWTのベストプラクティスでは、短命の
tokensと長命のrefresh_tokensが規定されています（更新トークンは取り消すことができます）。したがって、これは、失われる可能性のある無限のAPIトークンを配布するよりも安全です。
これはOAuth2だけではありませんか？
このアプローチは、基本的にoAuth2 "personal access"トークン付与シナリオです。 したがって、適切なoAuth2標準実装に対するこのようなカスタムトークン認証サーバーアプローチのメリットに疑問を投げかけますか？ ここでセキュリティが主な関心事である場合、このアプローチは実際にセキュリティリスクをもたらしますか？ 例： php-league-oatuh-2などのoAuth2のバトルテスト済み実装
現在の認証フローapplication-to-application認証の唯一の実行可能なユースケースが表示されますか？ oAuth2は、トークンを付与するための複数の認証フローメソッドをレイアウトします。 1つはこのアプローチが"personal access"を使用するものであり、もう1つは私が"password access"トークンを説明しているものです。 完全なoAuth2実装では、これらのシナリオとその他のシナリオの両方が可能になります...
さらに
開発者がステートレスAPI認証などに簡単にアクセスできれば、WP-APIの採用、つまりWordpressエコシステムの近代化が大幅に強化されると確信しています。
これらは単なる黙想であり、話し合い、貢献したいと思っています。
すごい仕事！
andrewmclagan
全てのコメント3件
私は、REST APIがコアになる前から、ネイティブアプリを構築してきました（または構築しようとしています）。 （すなわち：年）
当初、私のアプリがコンテンツを認証してアップロード/作成する唯一の方法は、APIチームが開始した「OAuth1.0a」プラグインを使用することでした。
これで、OAuth2.0で機能するようになりました（ここでも、追加のプラグインをインストールする必要がある別の機能です。これがコアになるかどうかはわかりません）
そして今、私のアプリを接続する方法に新しい問題を提示するJWTがあります。 当然、トークンを提供することで、ユーザー名/パスワードの方がうまく機能します。 （幸いなことに、この「WP-API」バージョンのJWTはトークンの更新をサポートしています。広く使用されている別のJWTプラグインはサポートしていません）
「箱から出して」（コアで）認証のための堅実な「ヘッドレス」/モバイル実装がないために、失われた機会（および時間）の膨大な量を信じることができません。
私のモバイルアプリは、その仕事をし、管理者関連のものの負荷とルート拡張をサポートするために独自のプラグインを必要とします。 カスタムブロックなど。アプリのユーザーや顧客に、別の「まだ完成していない」プラグインをダウンロードしてインストールさせる必要はありません。
確かな（そして「公式の」）解決策が存在することを願っています。
kosso
2019年12月17日
私は強く同意します。 Wordpressは、ヘッドレスcmsアリーナのリーダーになる立場にあります。 コアチームはそれに侵入しているようですが、おそらくwordpress.comの特定のユースケースを提供するためだけですか？ わからない。
現在、この目的のために同形クライアントを開発しています。 反応フックとプロバイダーと一緒に。 https://github.com/wp-headless/fetch。 おそらく、独自のJWT認証プラグインを作成する必要があります。 それがどのように見えるべきかについての私の考え：
- oAuth2の仕様に従います（カスタム認証フローを作成する理由）
- 複数のトークン付与方法があります：
password、machine-to-machine、api-keyなど。 - 十分にテストされた主要なパッケージに依存します。
andrewmclagan
2019年12月18日
ここでは、WP REST APIを介してユーザー登録/認証システムを実装しようとして立ち往生していますが、WPチームが新しいホイールを発明しているホイールを再発明していることがわかりました。
w33zy
2019年12月21日
関連する問題
jkmassel
·
7コメント
TiMESPLiNTER
·
3コメント
vamsiikrishna
·
3コメント
richangel
·
3コメント
patrick-mcdougle
·
3コメント
最も参考になるコメント
私は、REST APIがコアになる前から、ネイティブアプリを構築してきました（または構築しようとしています）。 （すなわち：年）
当初、私のアプリがコンテンツを認証してアップロード/作成する唯一の方法は、APIチームが開始した「OAuth1.0a」プラグインを使用することでした。
これで、OAuth2.0で機能するようになりました（ここでも、追加のプラグインをインストールする必要がある別の機能です。これがコアになるかどうかはわかりません）
そして今、私のアプリを接続する方法に新しい問題を提示するJWTがあります。 当然、トークンを提供することで、ユーザー名/パスワードの方がうまく機能します。 （幸いなことに、この「WP-API」バージョンのJWTはトークンの更新をサポートしています。広く使用されている別のJWTプラグインはサポートしていません）
「箱から出して」（コアで）認証のための堅実な「ヘッドレス」/モバイル実装がないために、失われた機会（および時間）の膨大な量を信じることができません。
私のモバイルアプリは、その仕事をし、管理者関連のものの負荷とルート拡張をサポートするために独自のプラグインを必要とします。 カスタムブロックなど。アプリのユーザーや顧客に、別の「まだ完成していない」プラグインをダウンロードしてインストールさせる必要はありません。
確かな（そして「公式の」）解決策が存在することを願っています。