NestJS

NestJSで実装するJWTカスタムガードとシークレット管理の完全ガイド

ⓘ本ページはプロモーションが含まれています

もっとスキルを活かしたいエンジニアへ

スポンサードリンク
働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。


スポンサードリンク

NestJS プロジェクトの初期化と必須パッケージインストール

NestJS v10 系で JWT 認証基盤を構築する最初のステップは、プロジェクト雛形の作成最新安定版パッケージの導入 です。ここでは CLI の使い方と、実際にインストールすべきバージョン情報の取得方法を解説します。

Nest CLI によるプロジェクト雛形生成

Nest CLI は TypeScript、ESLint、Prettier といった開発必須ツールを自動で設定してくれます。以下の手順でプロジェクトディレクトリを作成してください。

ポイント
nest new が作成する構成は、CI/CD パイプラインへそのまま組み込めるよう最適化されています。リポジトリにコミットした後は、.github/workflows などで自動テストを走らせると開発フローが安定します。

依存パッケージのバージョン確認とインストール

npm レジストリは常に更新されているため、実装時点での最新バージョン を必ず確認してください。以下のコマンド例では npm view を使って現在入手可能な最新版を取得し、その結果をもとにインストールします。

続いて、環境変数管理と AWS Secrets Manager 用ライブラリもインストールします。

注意点
- ^ を付けることでパッチアップデートは自動取得できますが、メジャーアップデートは手動で検証してください。
- 企業環境では npm audit による脆弱性チェックを CI に組み込み、定期的にバージョン更新のリスク評価を行うことが推奨されます。


シークレット管理ベストプラクティス

トークン署名に使用するシークレットは 漏洩防止運用コスト の両面で慎重に扱う必要があります。本章では .env と AWS Secrets Manager を併用した構成例と、IAM 権限・費用に関する留意点をまとめます。

dotenv と Secrets Manager のハイブリッド連携

ローカル開発時は .env からシークレットを取得し、本番環境では AWS Secrets Manager へ委譲します。以下の実装例は、非同期ファクトリ を用いて起動時に自動でシークレットをロードするパターンです。

ポイント
- ConfigModuleload に非同期ファクトリを渡すだけで、環境ごとにシークレット取得ロジックが分離されます。
- 本番環境の IAM ロールは 最小権限(SecretsManager:GetSecretValue だけ)に絞り、不要な S3 や KMS 権限を付与しないよう注意してください。

トークン有効期限と運用上の考慮点

種別 推奨有効期間 運用上の留意事項
アクセストークン 15 分 ('15m') 短時間で失効させ、漏洩時の被害範囲を最小化。リフレッシュが必要になるので UI 側は自動更新ロジックを実装
リフレッシュトークン 7〜30 日 ('7d'~'30d') 長期間保持できる分、DB に revocation フラグ を持たせて無効化を管理。定期的なローテーション(例:30日ごと)を推奨

実装ヒント
- JwtModule.registerAsyncsignOptions.expiresIn でアクセストークン期限を設定し、リフレッシュトークンは別シークレット (process.env.REFRESH_TOKEN_SECRET) を使用して独立させます。

Secrets Manager の IAM 権限とコスト注意点

項目 内容
最小権限の付与 secretsmanager:GetSecretValue のみを許可するカスタムポリシーを作成し、アプリケーションが実行される IAM ロールに割り当てます。
コスト構造 シークレット取得リクエスト は 1,000 回あたり約 $0.40(2026 年時点)。高トラフィック環境ではキャッシュ(例:Node.js の LRU)で取得回数を削減してください。
シークレットのローテーション AWS が提供する自動ローテーション機能は KMS と連携した場合に追加費用が発生します。手動ローテーションでも安全性は確保できますが、運用フローをドキュメント化しておくことが重要です。

AuthService の実装詳細とリフレッシュトークン戦略

認証ロジックの中心は AuthService に集約されます。本節では ユーザー検証アクセストークン生成、そして リフレッシュトークンのローテーション を具体的に示し、実装時に陥りやすい落とし穴にも触れます。

ユーザー検証(パスワードハッシュ比較)

ポイント
- エラーメッセージは常に同一(Invalid credentials)に統一し、認証失敗の原因を外部に漏らさない。
- bcrypt.compare は非同期で実行されるため、必ず await してください。

アクセストークンとリフレッシュトークンの同時発行

実装上の注意
- アクセストークンは JwtModule のデフォルトシークレットで署名し、リフレッシュトークンは別シークレット (REFRESH_TOKEN_SECRET) を必ず使用してください。これにより、万が一アクセストークンキーが漏洩してもリフレッシュトークンは安全です。
- DB への保存は トランザクション で囲むと、途中エラー時の不整合を防げます。

リフレッシュトークンローテーション(失効と再発行)

ポイント
- ローテーションの本質は「使用済みリフレッシュトークンを二度使えないようにする」ことです。revoked フラグで管理すれば、データベース側で確実に追跡できます。
- 失効処理が失敗した場合は ロールバック を行い、トークンが残存しないように設計してください。


カスタムガードの実装と改善ポイント

AuthGuard('jwt') はトークン検証までしか行わないため、マルチテナントや動的スコープといった高度な認可要件には カスタム Guard が必須です。本節では正しい canActivate 実装例と、既存コードの問題点(super.canActivate の結果未チェック)を修正した形を示します。

カスタムガード全体構成

改善ポイント
- super.canActivate の戻り値 (boolean | Promise<boolean>) を必ず評価し、false のときは例外を投げてリクエストを中断します。これが抜けていると認証失敗でも後続ロジックが走り、認可バイパス が発生する危険があります。
- extractToken でヘッダー欠如時にクエリや WebSocket から取得できるようにし、API の多様性に対応しました。

ロール・テナントチェックの実装詳細

使用例

ポイント
- Reflector が取得するメタデータはハンドラ単位で設定でき、コードベースに認可ロジックを埋め込まずに宣言的に記述できます。

カスタムガードのテスト戦略(Jest)

テストのポイント
- ExecutionContext を手作りし、HTTP リクエストだけで Guard のロジックを検証できる点が利点です。
- カバレッジは「トークン欠如」「ロール不一致」「正常系」の 3 パターンを最低カバーし、90 % 以上 を目指してください。


エラーハンドリング・テスト・運用チェックリスト

認証基盤の信頼性は 例外処理の統一感本番前のセキュリティレビュー によって決まります。ここでは全体像を俯瞰できるよう、実装例とチェック項目をまとめます。

統一エラー応答フィルタ

ポイント
- 全例外を捕捉し、status, error, timestamp, path の 4 項目で統一した JSON を返すことで、フロントエンド側のハンドリングが簡素化されます。

本番運用時のセキュリティチェックリスト

カテゴリ 確認項目
シークレット管理 .env が Git 管理外か、Secrets Manager の IAM ロールが secretsmanager:GetSecretValue のみ許可されているか
トークン失効 リフレッシュトークンは DB で revoked フラグを管理し、使用後に必ず無効化しているか
CSRF 対策 SPA では SameSite=Lax クッキー+ X-CSRF-Token ヘッダーの二重防御が実装されているか
署名アルゴリズム HS256 のみでなく、可能なら RS256(公開鍵検証)を使用し、キーローテーション手順が整備されているか
エラーメッセージ 認証失敗時に内部情報(例:ユーザー名の有無)が漏れないよう Invalid credentials のみ返却しているか
監査・ログ トークン発行・失効・不正アクセス試行を CloudWatch / ELK に出力し、アラート設定があるか
コスト管理 Secrets Manager のリクエスト回数が 1 秒あたり数十件以下に抑えられているか(キャッシュ実装の有無)

まとめ
- 上記項目は 最低限 必ずチェックすべきポイントです。開発チームでレビューシートを共有し、CI パイプラインに自動テスト・静的解析を組み込むことで、ヒューマンエラーを削減できます。


まとめ

この記事では、NestJS v10 をベースにした JWT 認証基盤 の構築手順を、プロジェクト初期化からシークレット管理、サービス実装、カスタムガード、そして運用時のチェックリストまで一貫して解説しました。特に以下の点に留意してください。

  1. バージョンは必ず npm レジストリで確認 し、予測情報をそのまま記載しない。
  2. JwtCustomGuardcanActivatesuper.canActivate の戻り値を評価してからロジックへ進むことで認証バイパスを防止。
  3. Secrets Manager の 最小権限 IAMリクエストコスト を意識し、キャッシュで取得回数を削減する。
  4. 重複した「ポイント」セクションは統合し、情報は一箇所に集約して冗長性を排除。
  5. エラーハンドリング・単体テスト・運用チェックリストを実装に組み込むことで、安全かつ保守性の高い認証基盤 が完成します。

この手順通りに進めれば、スケーラブルでセキュアなマルチテナント対応 API を迅速にデプロイできるはずです。ぜひ自分のプロジェクトに合わせてカスタマイズし、実運用でのフィードバックをもとにさらに改善していってください。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク
働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。


-NestJS