Feathers: 次の認証

パスポートの廃止

このディスカッションは＃844で始まり、 https： //github.com/feathersjs/feathers/issues/844#issuecomment -390123148で、これが発生する理由を要約してい

• ローカル（ユーザー名/パスワード）
• JWT
• oAuth（+ oAuthアクセストークン）
• APIキー

Passportを回避することなく、FeathersはHTTPライブラリやその他のトランスポートメカニズム（MQTTやP2P接続など）の上に簡単に配置でき、関心の分離を明確にし、理解とカスタマイズがはるかに簡単な認証メカニズムを提供します。

params.authentication

フェザー側では、サービス呼び出しでparams.authenticationを設定することが、認証情報を提供する唯一の方法になります。 params.authenticationには、サービスコールの認証に必要な情報が含まれ、すでに使用されている{ strategy: 'local', email: 'email', password: 'password' }の形式になります。

// Call `find` with a given JWT
app.service('messages').find({
  authentication: {
    strategy: 'jwt',
    accessToken: 'someJWT'
  }
});

呼び出し元（RESTまたはWebSocketトランスポート、フック、単体テストなど）は、 params.authentication合格する責任があります。 これは、 authenticateフックが内部呼び出しに対して実行されるかどうか、または認証情報が実際にどこから来ているかについて、混乱がなくなることを意味します。

authenticateフック

authenticateフックは引き続き存在します。 それは戦略名のリストを取り、どちらかになります

• エラーをスローしなかった最初の戦略で次のフックに進み、その戻り値（以下を参照）をparamsマージします

• または、すべての戦略が失敗した場合に失敗した最初の戦略のエラーをスローします

  params.authenticationにstrategy名前が含まれている場合、その戦略のみが呼び出されます。 それ以外の場合は、すべての戦略が呼び出されます。 params.authenticationがまったく設定されていない場合、フックは

• 外部呼び出しのエラーをスローします

• 内部呼び出しについては通常どおり続行します（たとえば、 params.user手動で設定する場合）

app.service('messages').hooks({
  before: authenticate('jwt', 'local', 'anonymous')
});

認証戦略

基本認証戦略が持つオブジェクトであるauthenticateのデータを取得する方法params.authenticationし、成功のオブジェクトを返すか、それが成功しなかった場合はエラーがスローされます。

const { Forbidden } = require('@feathersjs/errors');

const daveStrategy = {
  async authenticate (authParams) {
    const { username, password } = authParams;

    if (username === 'david' && password === 'secret') {
      return {
        user: {
          name: 'Dave',
          admin: true
        }
      };
    }

    throw new Forbidden('Not super Dave');
  }
};

app.authentication.registerStrategy('superdave', daveStrategy);

authenticateフックでは、返されたオブジェクトがサービス呼び出しparamsマージされるため、この例ではparams.userます。

戦略の拡張

認証戦略には、追加のメソッドを内部に含めて呼び出すことができます。 フェザー戦略は、拡張によってカスタマイズできるクラスとして実装されます（これにより、検証者が置き換えられ、基本的に戦略と検証者が1つのクラスに結合されます）。

class LocalStrategy {
  constructor(app);
  async findUser(authParams);
  async comparePassword(user, password);
  async authenticate (authParams);
}

class MyLocalStrategy extends LocalStrategy {
  async findUser(authParams);
}

app.authentication.registerStrategy('local', new MyLocalStrategy(app));

HTTP解析

ストラテジーは、基本的なノードHTTPリクエストとレスポンスを取得し、 params.authentication （またはnull ）の値を返すparseメソッドを提供することもできます。

const daveStrategy = {
  async authenticate (authParams) {
    throw new Forbidden('Not super Dave');
  }

  async parse (req, res) {
    const apiKey = req.headers['x-super-dave'];

    if (apiKey) {
      return {
        strategy: 'superdave',
        apiKey
      }
    }

    return null;
  }
};

HTTPライブラリは、これらのメソッドを使用してparams.authenticationか、独自のミドルウェアを認証するかどうか、およびどのように使用するかを決定できます。

app.authenticate

app.authenticate(authParams, [ strategies ])は、指定された認証パラメーターを使用して、指定された戦略を実行します。

// Will return the user for a JWT (on the server)
const { user } = app.authenticate({ accessToken }, 'jwt');

サービスコールでparams.authenticationを設定することは、認証情報を提供するための_唯一の_方法になります。

service()呼び出しごとにaccessTokenを提供する必要がある理由について、設計ポイントを説明してservice()ますか？

これはサーバーにのみ適用され、認証が構成されるとすべてのサービス呼び出しに設定されるparams.providerとparams.headers （WebSocketの場合はこれは偽のヘッダーのみ）を介して暗黙的に発生します。 これは、トランスポートプロトコルに依存しないフックとサービスと実際のトランスポートメカニズム（ExpressやSocket.ioを使用したHTTPなど）との間のFeathersの分離を壊し、たとえばauthenticate('jwt')フックが実際に実行され、それが何のために使用されているかを非常に混乱させましたその認証情報。

使いやすさに関しては、外部呼び出しまたは内部呼び出しで実際には何も変わりませんが、サーバーでauthenticateフックを明示的にトリガーする場合は、いつでもparams.authentication設定できます。 これは、Express以外の新しいフレームワークプラグイン（Koa、HTTP2、メッセージングキューなど）にとって特に重要です。これらのプラグインには、認証情報をFeathers認証メカニズムに渡すための標準化された方法があります。

認証クライアントは、 app.authenticate()呼び出してログインした後も、認証された要求を行います。

明確にしていただきありがとうございます。 v3、特にsocket.io ReactNativeクライアントでのテストを非常に楽しみにしています。

プレリリースに関する情報は間違いなくここにあります。 認証されたWebSocketをより確実に処理する必要がある認証クライアントをまとめるだけです。 それが完了したら、新しいコア+ローカルおよびjwt認証のテストに役立つことがあれば素晴らしいと思います。 その後、oAuthがすぐにフォローされるはずです。

バージョン3が出るのはいつですか？

私の質問への回答はありますか？

マスターブランチで現在の進捗状況を確認できます。ベータテスターが試してみることができるようになったら、ブログ投稿を公開します。 ステータスは次のとおりです。

| モジュール| コード| ドキュメント| CLI
| --- |：---：|：---：| ---：|
| @ femalesjs / authentication | ✅| 100％ | ❌|
| @ femalesjs / authentication-local | ✅| 80％| ❌|
| @ femalejs / authentication-oauth | ✅| 90％| ❌|
| @ femalesjs / authentication-client | ✅| 80％| ❌|

こんにちは、これは素晴らしいです！

将来の柔軟性は素晴らしいですが、私はまだFeathersJSプロジェクトの認証に自信がなく、それを作成するために混乱したプロセスを経ています。

完全でテスト済みの安全な認証実装があるということは、自信を持って機能に進むことができることを意味します。 MeteorJSを使用する最も良い理由の1つは、クライアントに至るまでの優れたアカウント統合でした。

FeatherJSの問題を見ると、多くは認証に関するものなので、この作業が着陸することに興奮しています。

今日のFeathersJSの完全な安全な認証システム（ローカル認証、アクセス制御、電子メールなど）の最良のドキュメント（またはリファレンス実装）はどこにありますか？

これは私がこれまでに持っているものです-もっと良いものはありますか？

2018 / 02-FeathersJSでの電子メール検証の設定（2017年の記事の再ハッシュ）
2018 / 02-上記の記事からのリポジトリ
2017 / 01-FeathersJSでメール検証を設定する方法（壊れています）
2018 / 06-Feathersjsを使用したVue認証

前もって感謝します！

これで、関連するすべての問題が解決され、提案されたすべての変更が実装されたFeathersv4のプレリリースがテストに利用できるようになりました。 詳細については、移行ガイドを参照してください。