ノード＆パスポート付きJWT：サーバーの再起動

Question

私はノードを初めて使用しており、ノード&のセットアップ時に認証時にJWTを作成するように設定しようとしています。

私は、「ステートレス認証メカニズム」を構築して、データベースに行き来する必要性を減らしたいと考えています。

共有秘密またはJWTがDBに保存されていない場合、サーバーが再起動すると、発行されたすべてのJWT（ログインユーザー）が無効になり、新しいJWTが必要になる保護されたルートにアクセスするすべてのユーザー私は、サーバが再起動するか、新しいインスタンスがスピンされるたびに、ユーザが再びログインするのを望まない。

私は、サーバの再起動に影響を与えない同じJWTを生成するために毎回使用できるノード環境に静的な共有秘密を渡すことができると信じています。

質問：

1. 良い練習はどこで、どのように私は、この共有シークレットを作成する必要があり、共有秘密に渡すことですか？すべての共有秘密を渡す必要がありますか？

2. しかし、ノード環境への共有秘密情報を渡すことは良い戦略ではない場合、私はすべての耳に耳を傾けていますか？私が言ったとき、私は秘密を共有することを意味

アップデート "キー（S）"。私は混乱しないように質問を更新します。

Answer 1

実際にこの種のアプリケーションには、キーを環境として渡すことをお勧めします。

環境は実行中のアプリケーションでのみ表示されるため、キーを漏らす可能性は低くなります（アプリケーションコードの残りの部分で提供される設定ファイルなどと比較して）。

通常、あなたは自分の環境を制御していると仮定して、たいてい1ヶ月に1回回転させるのが普通です。

しかし、鍵はあなたが署名したトークンであることを証明するためにのみ使用されています。通常は、パフォーマンス上の理由から、トークンにわずかな情報しか含めるのはお勧めできません。したがって、ユーザー自身に関する追加情報を取得するには、引き続きデータベースにアクセスする必要があります。トークンの内部にすべてのユーザー情報を追加できますが、各要求に対してトークンを送信する必要があり、オーバーヘッドがかかることに注意してください。

supervisordのようなプロセスマネージャを使用すると、そこに環境を設定して、設定ファイルに適切な権限を与えてキーの漏洩を防ぐことができます。

私は通常、ノードアプリケーションにそのような情報を渡すために環境を使用します。私はJWT、AWS鍵、SMTP資格証明などに使用します。コードを分離しておき、秘密鍵を公開コードのバージョン管理システムgithubのような。