問題タブ [express-jwt]

典型的な MEAN セットアップを実行しています。フロントエンド レンダリングに Angular、サーバーとして node.js (express) を使用します。静的 HTML/Javascript アセットは、認証を必要とせずにノードから提供されます。フロントエンドに表示されるすべてのデータは、Angular によってノードから要求されます。Angular は、ajax リクエストの「Authorization」ヘッダーでベアラー JWT トークンを提供することにより、ノード エンドポイントに対してユーザーを承認します。

これは完全に機能しますが、このセットアップでの Google API OAuth2 統合に関しては、私は行き詰まっています。目標は、ユーザーのカレンダー データを webapp に表示することです。

1. Angularは、リクエスト ヘッダーでベアラー トークンを提供するノードから/api/calendarsをリクエストします。
2. サーバーがそのユーザーの Google アクセス トークンをまだ持っていない場合、Google トークン要求 URL ( callbackUrl /api/calendars/googleCallback を含む) を作成し、これを Angular に送り返します。
3. Angular が応答としてカレンダー データの代わりに tokenRequest-Url を受け取ると、ユーザーをこの URL にリダイレクトし、Web アプリケーションのアクセス許可を手動で付与します。
4. Google は、アクセス コードを提供する callback-Url にリダイレクトします。

問題はステップ 4 です。ノード サーバーはステートレスであり、Google から/api/calendars/googleCallback?code=XYZへのリダイレクトには Authorization ヘッダーが含まれていないため、サーバーは識別できず、提供されたアクセス コードが属するユーザーを認証できません。

Google は事前に指定された固定のコールバック URL のみを受け入れるため、コールバック URL にユーザーを識別するある種のハッシュを動的に追加しても機能しません (とにかく安全ではないようです)。ユーザー ID を Cookie に保存することもできますが、これは全体的な JWT アプローチに違反しているように感じます。

上記のフローが一般的に悪い考えなのか、またはバックエンドがコールバックへのリクエストが属するユーザーを識別できるようにするために、この状況に対処するためのベスト プラクティスがあるのか​​という疑問があります。

ありがとう！

ユーザーがミドルウェア内で「jwt」として認証されているかどうかを確認したい。Passportjs に似た req.isAuthenticated() のような方法はありますか?

JWTを取得してペイロードをデコードできる場合、それはどのように安全ですか? ヘッダーからトークンを取得し、ペイロード内のユーザー情報をデコードして変更し、同じ正しいエンコードされたシークレットで送り返すことはできませんか?

安全でなければならないことはわかっていますが、テクノロジーを本当に理解したいだけです。私は何が欠けていますか？

私はトークンベースの認証にかなり慣れていません。カスタムの有効期限/トークン更新スキームの欠陥を見つけようとしています。

Express API で基本的な JWT 認証を設定しています。JWT の有効期限を 1 時間に設定しています。ただし、JWT は、トークンが発行された時刻を基準にしてトークンの有効期限をチェックします。API呼び出しが成功するたびに有効期限がリセットされることをお勧めします。ユーザーがアプリを 1 時間以上アクティブに使用している場合、トークンを更新するために再度ログインする必要はありません (そして、作業中のデータが失われる可能性があります)。

一方、トークンが 1 時間以上応答しない場合は、トークンを期限切れにしたいと考えています。

私は次のアプローチを思いつきました：

API リクエストが成功するたびに、新しい JWT を発行し、カスタム レスポンス ヘッダーで送信します。私のクライアント側コードは、この JWT 応答ヘッダーをチェックし、その値を新しいデフォルトの Authorization 要求ヘッダーとして使用する責任があります。したがって、ユーザーからの API 要求が 1 時間以上ない場合、トークンは期限切れになり、更新されません。ログインが必要になります。さらに、トークンの元の発行日 (ログイン認証のタイムスタンプ) が保存されるため、24 時間後にトークンの「ハード有効期限」が適用されます。

これはかなり簡単で、かなり安全に思えますが、私の JWT 調査ではこれに関する言及は見当たりませんでした。同じ目標を達成するためのより良い方法はありますか? このアプローチで主要なセキュリティ ホールを見逃していませんか?

更新: これについてしばらく考えた後、これの問題は、トークンの有効期限によって阻止できなかったリプレイ攻撃への扉を開くことであることに気付きました。したがって、絶対に「ハード有効期限」チェックが必要です。ハード有効期限は、最近のユーザー アクティビティに関係なく、発行日以降のある時点でトークンを無効にします。

CSRF から保護したい API エンドポイントがたくさんあります。これをステートレスでやりたいので、当然JWTが思い浮かびます。

問題は、これらのエンドポイントではユーザーがログインする必要がないことです。

したがって、私の問題は、JWT を使用できることですが、サーバー側でトークンを検証する方法がありません。照合できるログイン ユーザーがいません。

そのような場合にJWTを使用できる方法はありますか?

angularjs Web サイトのユーザー検証を行うために、expressJwt ( https://github.com/auth0/express-jwt ) を使用しています。誰でもこのページにアクセスできる URL (/username/somedata) があるという興味深い状況があります。ログインしていない場合、またはこのユーザーではない場合、パブリックとしてマークされたデータのみを取得します。ログインしていて正しいユーザーである場合、公開データと非公開データを取得します。

問題は、req.user から JWT (json Web トークン) にアクセスできるのは、/api (ログインが必要) で始まる任意のパスに限られることです...そして、このページはログインを必要としないため、落ちません。 /api の下。

/api の下にないパスで req.user へのアクセスを許可する方法はありますか? 別の考えは、データを要求して別のパスを使用する前に、ログインしているかどうかを確認することでした...

すなわち:

ログインしていない場合は常に次を使用します: /username/somedata (常に公開のみのデータ)

ログイン中: /api/username/somedata (出力する前に、ユーザーがデータの作成者であるかどうかを確認します。作成者が公開および非公開を出力する場合、それ以外の場合は公開のみ)

更新:複数のパスをテストしましたが、うまく機能していますが、別の方法で req.user にアクセスできるかどうかまだ知りたいので、まだ自分の質問には答えません。

Expressjs、nodejs、およびangularjsアプリでjsonwebtokenとexpress-jwtを使用して、ユーザー認証用のjson Webトークンを実装しようとしています。さまざまな記事やチュートリアルを読みましたが、今は少し混乱しています。

JWT について最初に理解したのは、JWT がピリオドで区切られた 3 つの部分で構成されていることです。

1. ヘッダー: jwt とアルゴリズムについて説明します。
2. ペイロード: 情報が含まれています: 発行者、オーディエンス、有効期限
3. 署名: ヘッダーとペイロードに基づく署名

したがって、すべてのリクエストはトークンを使用して行われ、サーバーで検証されます。この記事によると、発行者はリクエストを行う人です。ユーザー認証の場合、ユーザーは発行者です。現在、express-jwtミドルウェアを使用して、リクエスト ヘッダーのトークンを検証し、デコードされたトークンを req.user に添付します。

ペイロードの長さはどのくらいですか? Facebookの「ログインを維持する」のように、ユーザーがログアウトしない限り、ブラウザーを閉じた後でもセッションが持続するように、クライアント側でトークンを保存する方法と場所は? トークンの有効期限が切れた場合にユーザーに再度ログインを求めるプロンプトが表示されないようにするため、ユーザーがログアウトしない限り、トークンを更新する必要があります。

nodejs、express、angularjs アプリに jwt 認証を実装しようとしています。これまでのところ、トークンを生成し、localStorage. このチュートリアルに従って、次のように in angular factory を実装しましauthInterceptorた。

次のように、インターセプターを構成ファイルにプッシュしました。

これまでのところ、認証情報をサーバーに送信し、トークンを生成して に保存しましたlocalStorage。

そのため、localStorage からトークンを削除しておらず、トークンの有効期限が切れていない限り、トークンは存続するはずです。angularjsのバックグラウンドajax呼び出しを使用して、ロードされたページ内からリクエストを行うと、認証ヘッダーが想定どおりに設定されます。

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYSIsInR5cGUiOiJzYWxlcyIsImlhdCI6MTQyMjI2MDExMCwiZXhwIjoxNDIyMjc4MTEwfQ.Iv6W-Tc8Qm4FGclzmgbtjvWFz_tyDwEvrFmMmucONpY

ただし、新しいルートに移動しても、リクエストもレスポンスも傍受されません。たとえば、「/sales」ルートがあります。しかし、アドレスバーから販売ルートに移動すると、インターセプターによってリクエスト認証ヘッダーが設定されないため、サーバーから認証エラー 401 が返されますが、これもインターセプトされません。したがって、にリダイレクトしません/dash。

エラーのリンクと、承認されていないルート '/sales' への GET 要求のヘッダーは次のとおりです。

これが私のユースケースです。

Express-jwt モジュールを使用するエクスプレス アプリには、2 つのメイン ルートがあります。ルートを 2 つの異なるパスフレーズで保護したいと考えています。

この場合、私が期待していたようには機能しません... 1 つの高速アプリだけでこれを実現する方法はありますか?

あなたの助けを前もってありがとう！