Feathers: Passport JSを廃止しますか？

認証を行うためのフレームワークに依存しない方法を検討し始めたので、これは実際には良いタイミングです。 Express、Koa、またはHapiトランスポートでFeathersを使用している場合は、oAuthのみをサポートしても問題ありません。

残念ながら、これはかなり重大な重大な変更を意味する可能性があり、認証がフェザーの人々にとって最も困難な部分であるように思われることを考えると、リスクがあります。

このlibは役立つ可能性があります：
https://github.com/ianstormtaylor/permit

Passportの大きなセールスポイントはそのエコシステムです（Passportはそのエコシステムの重要な部分であるため、Express全般にも当てはまります）。 GrantはPassportの最も実行可能な代替手段ですが、Passportほど開発されておらず、機能（さようなら、passport-local）がありません。
Passportのフレームワーク（不可知論者）アダプターへの投資は面倒ですが、物事を壊さないための唯一の方法だと思います。 いくつかのイニシアチブがありましたが、 https：//github.com/hapijs/travelogueのようにすべてが放棄されてい

その理由はおそらく努力する価値がないからでしょう。 PassportJSの問題は

1）今ではPassportコア（過去3年間で2つのリリース）とほとんどのプラグインはほとんどメンテナンスされていないようです
2）活動が少ないということは、それがより安定していることを意味することもありますが、ほとんどの問題から判断すると、完全に未確認のままであると私は推測しています1）
3）他のフレームワークではうまく機能しません
4）Websocketではうまく機能しません
5）HTTP2または完全に非HTTPトランスポートプロトコル（Feathersがサポートできる）では、それほどではない可能性が非常に高いです。

そして最終的には、特にプロトコルに依存しないアーキテクチャを強制しようとするFeathersの場合、実際にはあまり効果がありません。 現在、基本的に変換しています

Feathers protocol independent format -> Passport friendly (HTTP like) format -> Passport strategy -> Custom code in passport strategy -> Strategy return value -> Feathers format

私たちが本当にやりたいことは

Feathers protocol independent format -> Custom verification code -> Feathers format

passport-localようなものはすべて、ユーザー名とパスワードを比較するだけです（とにかく、これは独自のハンドラーで行う必要があります）。それでは、フックに貼り付けてみませんか？

最大の課題は常にoAuthです。これは幸運にも標準であるため、より優れた代替手段が存在する可能性があります。 実際には、Feathers自体は、oAuthアクセストークンを有効なJWTに変換できるようにする以外に、oAuthについてそれほど心配する必要はありません。 他のすべては、Feathersを使用することになったフレームワークで実行できます（おそらく実行する必要があります）。

ポイントは有効なようです。 @daffl 、このアーキテクチャ内のExpress（および場合によってはKoa）エンジン専用の現在のパスワードベースの認証モジュールとの互換性を維持することについてどう思いますか？

フレームワークがPassportとの互換性を失い、開発者がその戦略のためにそれを必要としている場合、現在の方法と同様にフレームワークを統合するためにraw Passportを実装することは、簡単な作業ではありません。 現在のfeathers-auth- *パッケージには、エラー処理などのためのテスト済みの便利な定型コードがたくさん含まれています。

私にとって大きな問題（そして私は一人ではないと思います）は、Feathersがステロイド上のExpressであり、最終的には、規則、多数の重要な機能、およびPassportを含む既存のExpressエコシステムを使用する機能を備えたフレームワークのように感じることです。 これはFeathersの非常に強力な側面だと思います。プロジェクトを次の主要なフレームワークのリリースに移行し、機能の低下に対処するために多大な労力が必要になるとしたら、残念です。

ええと、Feathersがフレームワークに依存しないように変更されたとき、Expressのサポートが失われることはなかったので、同様の考えです。 これを前進させ、他のフレームワークやプロトコルを実際にサポートするために、残念ながら、認証のために同様のことを行う方法は実際にはありません。 高レベルのAPIはほぼ同じままですが、内部はより柔軟になるように変更されます。

とにかくすでにFeathersプラグインによってサポート（および抽象化）されているもの以外は、Passport戦略があまり使用されていないように感じます（実際には、特にWebSocketを介して機能しないものもいくつか知っています） 。 ほとんどのAPIで、認証のユースケースはそれほど多くありません。

• JWT（+リフレッシュトークン）
• ユーザー名パスワード
• その他のトークン（APIキー、oAuth accessTokenなど）

これは私たちが現在抱えている問題の1つです。 ほとんどのFeathersは問題を開いており、Cookie、セッション、リダイレクト、および認証クライアントをいじくり回しているのは、ほとんどの場合、すべてのFeathersが本当に必要とするのはアクセストークンである場合のPassportとoAuthによるものです。 より良い分離は、物事をより明確にし、カスタマイズしやすくします。

PassportJSがより積極的に保守されていれば、これらすべてがおそらくそれほど多くの問題を引き起こすことはないでしょう。 他のフレームワークをサポートすることは、私には一般的な認証レイヤーにとって非常に重要な機能のように思えますが、すべての新しいフレームワークは、それ自体でよりモジュール化された（そして最小限の）認証メカニズムになってしまったようです。

認証は、人々にとってフェザーの最も難しい部分のようです。

この感情を反映させたいと思います。 私が（初心者として）feathersを試すことにした主な理由の1つは、それがまともな認証チュートリアルさえ持っている唯一のapiフレームワークの1つであるということです。 また、feather独自の認証実装を採用するのがおそらく最善の方法であり、私のような人々がFeatherを操作しやすくなると思います。

認証システムに変更を加える際は、デフォルトとして通常のCookieセッションに切り替えることを強くお勧めします。JWTは後方サポートオプションとしてのみ使用します。

JWTは、セッションのような認証に使用するようには設計されておらず、通常のCookieセッションに比べて意味のある利点はありませんが、CookieセッションはJWTに比べて大きな利点があります（JWTが脆弱なセッションハイジャック保護を含む）。

この講演は、その理由（そして、そもそもJWTがどのように人気を博したか）を説明する優れた仕事をしています：

この記事は別の良いリファレンスです： http ：

FeathersはセッションにJWTを使用しておらず、 https： //github.com/feathersjs/authentication/issues/597#issuecomment-339846437の記事で取り上げられた懸念のほとんどにすでに対処しています。 オープンフェザーの問題の大部分は、JWTの問題ではなく、実際にCookieを使用することに関する問題です。

JWTを選択した理由はたくさんあります。 最も重要なのは、Feathersが非HTTPトランスポートメカニズムをサポートするように設計されていることです。 セッションCookieへのWebSocket接続のシューホーニングを試したことのある人なら誰でも、おそらく私が何を意味するのかを知っているでしょう。JWTでうまく機能する他のトランスポート（計画されたMQTTなど）ではまったく不可能です。 私もいつも指摘しているように、それが本当に必要な場合は、Feathers用に独自のExpressミドルウェアベースの認証メカニズムを実装するのはかなり簡単です。

app.use(function(req,res, next) {
  // Set service call `param.user` from `session.user`
  req.feathers.user = req.session.user;
});

authtリポジトリへのリンクをありがとう。 ここだけでなく、セッション関連の問題についても、ここでさらに検索することができませんでした。

私の知る限り、Cookieの使用に問題があるWebSocketについては聞いたことがありません。 http以外のリクエストの場合、Cookieに使用されるのと同じトークンをログイントークンとして指定できます。 これにより、デフォルトでhttpベースのリクエストがより安全に（そして標準的に）なり、他のサービスにも同じように簡単に実装できます。 また、トークンを取り消すことができるようになりました。これにより、非常に簡単にできるようになりました（また、パスワードのリセットや手動の「すべてログアウト」などのために、開いているすべてのセッションをクリアすることもできます）。

理想的には、JWTに固執する場合は、決定の背後にある完全な理由を概説し、それらについて提起されたすべての懸念、それらが適用されない理由、またはトレードオフの決定が行われた理由を含むドキュメントページを用意する必要があります。

Feathers v4認証は完全にフレームワークに依存せず、PassportJSに依存しなくなりました。 JWTのファンではなく、Grant for oAuthを使用している場合にカスタムアクセストークンの使用を許可する場合（これにより、作業がはるかに簡単になります）。 アップグレード方法の詳細については、移行ガイドを参照してください。