Jwt-auth: トークンフローUXを更新しました

このすべてを書き出すために時間を割いていただきありがとうございます。 以下の何かが厳しいと感じた場合、それは意図されたものではありません。私はあなたに私の意見を述べているだけであり、それだけではありません。それらが混在している可能性があり、議論は問題ありません。

この変更により、ユーザー名とパスワードを使用してログインできることを期待している技術者以外のほとんどのユーザーが、このプラグインの機能にアクセスできなくなるのではないかと心配しています。

私はあなたがここで言おうとしていることを理解しますが、同時にあなたが提案していることは、ユーザーにWordPressにログインしてキーペアを作成することを要求することは、トークンを生成したい非技術的なユーザーにとってはどういうわけか難しいということですプログラムでRESTAPIを介して。 これらは_非技術的な_ユーザーではないと私は主張します。

同様に、すべての安全なシステムには、ユーザーがそれを使用するために克服しなければならない参入障壁があります。 Googleでは、APIリクエストでユーザー名とパスワードを使用してJWTまたはOAuth接続を作成することは許可されていません。 それは安全ではありません。 トークンまたは認証接続が無効にできる方法でユーザーに接続されていることを確認する方法が必要です。

直感的ではありません
この方法を使用してWordPressと統合したい他のシステムでは、開始するためにキーペアを設定する方法の説明/チュートリアルが必要になります。

アクセスと認証の分離をサポートする安全なモデルを作成するには、長期間有効なトークンが無限のアクセスポイントにならないようにするガードレールが必要です。 更新トークンを追加すると、悪意のあるユーザーがuser:pass組み合わせでアクセストークンと更新トークンを作成する可能性があります。これは、トークンを無効にするキーペアまたは同等のものがない場合は無効にできません。

WordPressにログインし、プロファイルに移動してキーペアを生成するようにユーザーに指示することは、セキュリティのために支払う小さな代償です。 同様に、指示は非常に簡単です。

デバイス間での使用は難しい
このキーを携帯電話のアプリに使用したい場合、そこに到達する簡単な方法はありません。 長い文字列、数字、特殊文字を携帯電話に入力したくありません。文字起こしエラーが発生する可能性があります。 人々がスキャンできるQRコードを生成することで、文字起こしの難易度を取り除くことができますが、その後、上記の問題に戻ります。人々はQRコードアプリをダウンロードする必要があるか、サードパーティの開発者がQRコードを作成する必要があります。私たちと協力するために、ライブラリをアプリに解析します。

あなたが参照し続けるこのアプリについて説明してください、なぜそれはあなたのためにすべての認証とログインを処理するのですか？ それは安全ではありません。 あなたはこのアプリにあなたのウェブサイトにやりたいことをするために必要なすべてのアクセスと認証を与えるでしょう。 アプリのアーキテクチャが正しくない可能性があることを考慮する必要があります。この認証フローは、説明している内容を正確に防ぐためのものです。

あなたが私に説明したのは、プレーンテキストのユーザー名とパスワードを保存するアプリです。これにより、REST APIを介してWordPressにログインし、リソースへのアクセスに使用されるトークンを生成できますが、同じものを介してデータベースを完全にダンプすることもできます。認証とアクセスの手段。 あなたが説明したように、なぜこのユースケースに近いものをサポートしたいのかわかりません。

それは良いセキュリティ衛生を促進しません
理想的には、ユーザーはキーを慎重に管理して、古くなったり、侵害されていないなどの問題がないことを確認します。残念ながら、これを当てにすることはできません。侵害されたキーは、侵害されたトークンよりもさらに危険です。 また、平均的なユーザーは、秘密を安全な場所に保存するのではなく、必要になるたびに新しいキーを作成する可能性があります。

まず、キーペアは有効期限に関連付けられておらず、現在実行できるのはトークンを作成することだけです。そのため、トークンを無効にするものであるため、侵害されたトークンよりも「危険」であることがわかりません。 第二に、ユーザーは慎重に何もしません。ユーザーが自分の行動のセキュリティへの影響を理解することを期待してはなりません。 私たちは、彼らが非常に無能であり、自分たちの後片付けを決してしないほど怠惰である可能性が高いと想定する必要があります。 ただし、追加のキーペアを作成することはセキュリティの問題ではありません。 セキュリティの問題は、プレーンテキストのユーザー名とパスワードを外国のアプリに与えることです。

さらに、セッションを取り消すためのメソッドを追加することを懸念しています。WordPressのプロファイルページにはすでに[他の場所からログアウト]ボタンがあります。ユーザーとして、アプリケーションからもログアウトすることを期待しています（または少なくとも私がそれをしたいかどうか私に促しますか？）

キーペアを削除するようにユーザーに促すことはできますが、ログアウトによってトークンが破壊されることはありません。 これは、このようなシステムの通常の動作または予想される動作ではなく、混乱と大量のサポート要求を引き起こす可能性があります。

追加のセキュリティは提供されません
攻撃者としての私がすでにあなたのユーザー名とパスワードを持っている場合、私があなたとしてできないことは何もありません（2FAが設定されていないことを前提としています）。

私は断固として同意しません。 このアプローチは、RESTリソースにアクセスするための追加のセキュリティを提供します。それが明らかでない場合は、それを明確にするためにさらにドキュメントが必要です。 あなたは、誰かがすでにあなたの資格情報を持っているなら、あなたは困惑していると主張していますが、RESTAPIへのアクセスを与えるためにそれらを使用することも提案しています。 それがRESTにアクセスする方法である場合は、基本認証を使用します。 これは、 user:passを使用してトークンを作成する場合に実装するものとまったく同じだからです。

これは、私が初心者のアプリケーション開発者としてユーザーの生活を楽にしたい場合、ヘッドレスブラウザーを使用してユーザーのアカウントにログインし、トークンを作成し、詳細を読んでから、などの望ましくないことを試みる可能性があるという事実につながります。それらを私のアプリに戻します。

これは、コールバックを使用してアプリにキーペアを与えることを可能にする認証フローを作成する場所です。 このようなものは、アプリケーションパスワードプラグインにすでに実装されていると思います。

私はアプリの認証フローを作成することに100％オープンです。アプリにアクセスすると、WordPressにログインするように求められ、2factorなどの追加機能が追加されます。これにより、キーペアが生成され、何らかのコールバックが使用されます。アプリにキーペアを渡します。 そうすれば、アプリ開発者は大量の悪いソリューションを作成する必要がなく、アプリはuser:pass保存しません。

代わりに何ができるでしょうか？
キーは現在、重要な目的を果たしています。トークンの寿命が非常に長い可能性があるにもかかわらず、トークンの失効を許可するために使用されています。 ただし、これを行うために必ずしもキーペアは必要ありません。

正解です。さまざまなアプローチを使用できます。

usermetaのWordPressのsession_tokensエントリ（JWT固有の失効キーの保存されたセット）からインスピレーションを得て、同じ機能を許可し、「他の場所でログアウト」機能を実装するのは簡単です。テーブルからそのエントリを削除するだけです。

これは、追加する必要のある現在の実装に置き換わるものではありません。 私は、エンタープライズソフトウェア開発者として、この方法を決して使用しません。 したがって、これは有効なアプローチですが、有効期限が切れていないか、トークンが取り消されていない限り、トークンが有効であると期待する機能がありません。 あなたのシナリオでは、2番目にログアウトするとトークンは無効になります。 これは、認証フローのIMOの欠陥であり、ログインしているユーザーと緊密に結合されているため、アプリがリソースにアクセスする機能に無数の問題を引き起こします。

2FAはどうですか？
2FAプラグインが必要であるが提供されていない場合に、クライアントに「2FAトークンを提供して、もう一度やり直してください」と伝えるために使用できるフックを許可できるかどうか疑問に思っています。 さらに、別のフック（またはおそらく同じフック？）を使用して、2FAプラグインが提供されたコードが正しいことを確認できるようにすることができますか？ JWTシステムは、2FAがどのように実装されているか（別のプラグインに任されている）については何も想定していません。そのようなことを可能にするためのフックを提供するだけです。

これにより、IMOは、多くのサポート要求を作成する可能性のある不必要な複雑さの層を追加します。

ここまで読んでいただきありがとうございます。上記はすべて私見ですが、ユーザーがこのプロセスを少し単純化して、誰にとってもすぐに使えるようにできることを願っています。

私は少なくとも何かを逃したと確信しているので、人々がこれについて持っているかもしれないフィードバックを聞いてうれしいです！

壮大な投稿。 このすべてを書き留めていただきありがとうございます。 あなたは本当にこれに多くのことを考えました。 私は何も撃墜しようとしているのではないと言いたいです。 user:pass組み合わせでトークンを作成できるようにする場合、その方法は非常に安全であり、アプリがログイン資格情報を保存する可能性がゼロである必要があります。

アクセスと認証を分離するという点は意図的なものであり、軽視すべきではありません。 インターネットの1/3の潜在的なREST認証を構築しています。 そのため、進むべき道が見つかるまで、ユーザーの資格情報を使用してトークンを作成する機能を削除しました。 これは、追加できないという意味ではありません。追加する前に、多くの議論が必要なだけです。

やあ！ 私が理解していることから、ここでの会話の主な問題点は使いやすさです。 実際、ユーザーがログインしてキーペアを作成するためにサイトにアクセスすることは、一部のユーザーにとって問題または不便の原因になります。

開発者は、今日、ユーザーのために強力なパスワードを必要とする機能を削除するのと同じ方法で、それを回避するための安全でない方法を見つけようとする可能性があります。

私は決定におけるセキュリティの側面を理解していますが、ある程度同意します。 しかし、私たちは両方のために働くことができる方法を見つける必要があります。

ここであなたが言ったことは@valendesignsが可能な解決策かもしれないようです：

私はアプリの認証フローを作成することに100％オープンです。アプリにアクセスすると、WordPressにログインするように求められ、2factorなどの追加機能が追加されます。これにより、キーペアが生成され、何らかのコールバックが使用されます。アプリにキーペアを渡します。 そうすれば、アプリ開発者は大量の悪いソリューションを作成する必要がなく、アプリはuser：passを保存しません

私が理解していることから、基本的には現在のフローを維持します。これは、トークンを生成するためにキーペアのみを与える代わりにアプリにパスワードを与える必要がないため、より安全ですが、それは一部の人にとってハードルになる可能性があります。

外国のアプリにパスワードを与える必要がない場所で、この他のフローを維持します。 代わりに、WordPressにログインしてキーペアを生成するように依頼します。

この部分についてもっと情報が欲しいのですが：

キーペアを削除するようにユーザーに促すことはできますが、ログアウトによってトークンが破壊されることはありません。 これは、このようなシステムの通常の動作または予想される動作ではなく、混乱と大量のサポート要求を引き起こす可能性があります。

ブラウザとアプリを介してsite.comにログインしている場合は表示されますが、ブラウザの[他の場所からログアウト]をクリックすると、アプリからもログアウトされます。 これが想定されるアプリを見ることができます。 あなたがどこでもログアウトするだろうという期待。

アカウントが削除されたときにも同じことが起こる必要があります。

キーペアUXが非常にユーザーフレンドリーであるということについて言われたことに同意する必要があります。

このAuthメソッドを使用できるネイティブモバイルアプリを構築することは非常に困難です。

• しばらく前に、アプリケーション管理ページに暗号化された（短く設定可能なパスワードを使用して）QRコードを表示する（古い）OAuth1aプラグイン用のカスタムプラグインを作成しました（アプリ名とコールバックURLがアプリケーションと一致した場合）。クライアントアプリの情報をモバイルアプリに渡して、ユーザーが認証できるようにします。

確かに（しゃれを意図して）、JWTはOAuth1aよりもはるかに簡単です;）

ユーザーは最初に（できればhttps経由で）Wordpressにユーザー名とパスワードを使用してログインする必要があるため、ユーザー名とパスワードのペアがアクセストークンを取得できるというセキュリティ上の問題が何であるかはわかりません。 ？ それはすべて、一日の終わりに同じ「ワイヤー」を介して送信されていますか？ もちろん？

現在実装されているアプリケーションのキーペアを適用すると、この認証方法をモバイルアプリケーションで使用することは（現実の世界では）絶対に不可能になります。

モバイルアプリをそれらに入力させるための正しい方法はありません。

私はOAuth1a、OAuth2、そして今では2つのJWTプラグインを試して、アクセス可能なネイティブアプリを実装しましたが、ユーザーのために何かを試してみるためにハッキングすることなく、すべてが「すぐに使える」失敗に終わります。 確かに、このようなものは簡単になるはずですか？

そこにあるサードパーティのJWTプラグイン（インストール数が10,000以上）はユーザー/パスをサポートしており、私が構築しているネイティブモバイルアプリケーションでうまく機能します。 ただし、プラグインを介した更新トークンがない場合は失敗し、ユーザーは再度「ログイン」する必要があります。 （wp-configを手動で編集する必要もあります）

この「まもなく公式になる」（私は願っています！）プラグインは、モバイルユーザーフレンドリーの欠如と、そのために実際に開発できるアプリケーションの種類を無視しているように見えるために失敗します。 そして、それは非常に近視眼的なようです。

wp.​​orgサイトに投稿するためのネイティブモバイルアプリが不足しているのには理由があります。 そして、これです。

お願いします、これについて何か動きをもらえますか？ （私は、REST APIの導入以来、ユーザーを認証するための「適切な」方法を待って、何年もの間ネイティブアプリに取り組んできました）

:)

トークンフローUXは非常識であり、実際の使用には実用的ではありません。ユーザーはシステムにユーザー名とパスワードを使用してログインでき、APIキーのペアを要求しても意味がありません。ここでは抽象化を採用していません。アプリケーションの使用に関する技術からユーザーを保護するために、電話でFacebookにログインするには、Facebookの管理ポータルにログインしてAPIキーペアを作成してから、APIキーペアを使用する必要があるとどのように感じますか。ログインするために、私たちは開発者向けに開発しているのではなく、サービスの技術的側面が何であるかを知らない顧客向けに開発しており、すぐにアンインストールします。 このプラグインが認証にどのように役立つのか、私にはよくわかりません。

ユーザーログイン>トークンフローに関するこの問題は、JWTを使用している可能性のある非常に多くのアプリの開発を深刻に妨げています。

何ヶ月も何ヶ月も経ち続けており、それは単に対処されていません。

上で述べたように、ユーザーが実際に管理者にログインするためにユーザー名とパスワードのペアを使用するという事実は、トークンを取得するためにユーザー名とパスワードのペアを使用しないことを使用することについて何らかの議論をしますか？ もちろん？

このスレッドを更新するだけです。このプロジェクトは、WPコアに完全なOAuthフローを実装するために置き換えられているようです。 すべての長所を維持しながら、ここで説明するアプローチの欠点に対処する必要があります。

これに参加したい場合は、Slackの＃core-restapiに気軽にアクセスしてください。