スキル auth-implementation-patterns
🔐

auth-implementation-patterns

安全

安全な認証システムの実装

こちらからも入手できます: wshobson

実践で実証済みの認証と認可のパターンを学び、车組み直すことなくアプリケーションに安全なアクセス制御を構築します。

対応: Claude Codex Code(CC)
🥉 75 ブロンズ
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「auth-implementation-patterns」を使用しています。 ExpressでJWT認証を実装するにはどうすればいいですか？

期待される結果:

完全なJWT実装には以下が含まれます：1）環境変数のシークレットを使用してjwt.sign()でトークンを生成、2）Bearerトークンを検証する認証ミドルウェアを作成、3）より長いリフレッシュトークン（7d）と短い有効期間のアクセストークン（15分）を使用、4）データベースにハッシュ化されたリフレッシュトークンを保存。完全コードはimplementation-playbook.mdパターン1を参照してください。

「auth-implementation-patterns」を使用しています。 セッション認証とトークンベース認証の違いは何ですか？

期待される結果:

セッション認証：サーバーが状態を保存し、クッキーにセッションIDを使用しシンプルだがスティッキーセッションが必要。トークンベース（JWT）：ステートレスで自己完結型のクレームを持ち水平にスケーリングするが、個々のトークンを簡単に取り消せない。伝統的なアプリにはセッションを、APIやマイクロサービスにはJWTを選択してください。

「auth-implementation-patterns」を使用しています。 ロールベース認可を実装するにはどうすればいいですか？

期待される結果:

列挙型（USER, MODERATOR, ADMIN）でロールを定義し、ロール階層マッピングを作成し、許可されたロールに対してユーザーロールをチェックするrequireRole()ミドルウェアを構築し、保護されたルートにミドルウェアを適用します。例：app.delete('/users/:id', authenticate, requireRole('ADMIN'), handler)

セキュリティ監査

安全
v1 • 2/24/2026

Educational documentation skill containing authentication and authorization code patterns. All 67 static findings are false positives: backticks are markdown code fences, environment variable access demonstrates proper secret handling, and weak crypto mentions are in cautionary context. No actual security risks present.

2
スキャンされたファイル
661
解析された行数
0
検出結果
1
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
50
コミュニティ
100
セキュリティ
100
仕様準拠

作れるもの

ゼロからJWT認証を構築する

適切なシークレット管理を備えたアクセストークン、リフレッシュトークンを含む完全なトークンベース認証を実装する

OAuth2ソーシャルログインを追加する

GoogleとGitHub OAuth2認証を既存のアプリケーションに統合する

認可モデルを設計する

アプリケーションリソース用のRBACまたはパーミッションアクセス制御システムを作成する

これらのプロンプトを試す

基本的なJWTセットアップ 
ExpressでNode.jsを使用してJWT認証を実装する方法を示してください。トークン生成と検証ミドルウェアを含みます
リフレッシュトークンフロー 
データベースにリフレッシュトークンを安全に保存し、新しいアクセストークンを発行するリフレッシュトークンフローを作成します
OAuth2統合 
Passport.jsを使用してGoogle OAuth2ログインを実装し、認証後にJWTトークンを生成します
RBAC認可 
 
 
ベストプラクティス
 
  •  Always use environment variables for secrets (JWT_SECRET, SESSION_SECRET) never hardcode credentials
  •  Use short-lived access tokens (15-30 minutes) with separate refresh tokens for better security
  •  Store refresh tokens hashed in database and implement token rotation on use
 
 
回避
 
  •  JWTをlocalStorageに保存するとXSS攻撃にさらされる - httpOnlyクッキー代わりに使用
  •  トークンの有効期限を検証しないと同じトークンが無期限に使用できる
  •  クライアント側だけの認可チェックはバイパスできる - 常にサーバー側で検証する
 
 
よくある質問
 
セッション認証とトークンベース認証はいつ使用すべきですか？  
シンプルなログアウトとCSRF保護が必要な従来のサーバーレンダリングアプリにはセッションを使用。ステートレスな認証とクロスドメインリクエストが必要なSPA、モバイルアプリ、マイクロサービスにはトークン（JWT）を使用します。
JWTシークレットを安全に保存するにはどうすればいいですか？  
シークレットをソースコードにハードコードしないでください。環境変数（process.env.JWT_SECRET）を使用し、実行時に.envファイルからロードします。.envが.gitignoreにあることを確認し、本番環境ではシークレットを安全なソースから注入してください。
認証と認可の違いは何ですか？  
認証（AuthN）はユーザーが誰であるかを検証します（資格情報でログイン）。認可（AuthZ）はユーザーが何ができるかを決定します（パミッション、ロール）。両方ともアクセス制御において不可欠だが異なる目的を果たします。
リフレッシュトークンを安全に実装するにはどうすればいいですか？  
リフレッシュトークンをランダムなUUIDとして生成し、データベースにハッシュ化されたバージョンを保存し、有効期限を設定（7-30日）、ローテーションを実装（使用ごとに新しいリフレッシュトークンを発行）、ログアウトやセキュリティイベントのために失効を許可します。
JWTトークンは失効できますか？  
JWTは本質的にステートレスです。失効方法：Redis/データベースにトークンブロックリストを使用、自然に期限切れになる短い有効期限を設定、または古いトークンペアを無効にするリフレッシュトークンローテーションを使用します。
パスワード保存の最佳な方法は何ですか？  
常にbcryptまたはargon2で高いコスト係数（bcryptコスト10-12）を使用してパスワードをハッシュ化。平文パスワードを保存しないでください。bcryptが自動的に提供するソルトを使用。bcrypt.compare()で検証します。
 
 
開発者の詳細
 
作成者
 sickn33
 
ライセンス
 
MIT
 
リポジトリ
 https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/auth-implementation-patterns
 
参照
 
main
 
ファイル構成
 
📁 resources/
 
📄 implementation-playbook.md
 
📄 SKILL.md