本文へ移動
cccskills
無料GitHub で公開日本語紹介

building-api-authentication

JWT、OAuth 2.0、APIキー、セッション認証を使ったAPIの認証・認可を実装し、トークン更新や権限確認、ログイン試行の保護まで整えるスキルです。

原文原文の説明を見る

Build secure API authentication systems with OAuth2, JWT, API keys, and session management. Use when implementing secure authentication flows. Trigger with phrases like "build authentication", "add API auth", or "secure the API".

jeremylongshore/tons-of-skills-marketplaceスター 2,884(GitHub 2,884 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • APIにログイン認証を追加したいとき
  • ユーザーの役割や範囲でアクセスを制御
  • APIキーでサービス間通信を行いたいとき
  • 認証フローのセキュリティテスト

日本語での紹介

できること

APIにJWT Bearerトークン、OAuth 2.0、APIキー、セッション認証を組み込みます。ログイン時のトークン発行、署名と有効期限の検証、リフレッシュトークンのローテーション、失効処理を整え、ユーザーの役割やスコープに応じてエンドポイントへのアクセスを制御します。機械同士の通信向けAPIキーやサービス間認証、複数のOAuthプロバイダーとの連携にも対応します。ログイン試行の制限や段階的なロックアウトを加え、トークンの有効性、権限、キー検証などを確認するセキュリティテストも作成します。

こんなときに便利

APIにログイン機能や認可の仕組みを追加したいとき、既存の認証方式を調べて保護が抜けたエンドポイントを確認したいときに使えます。役割や操作範囲ごとにアクセスを分けたい場合や、APIキーを安全に発行・検証したい場合にも向いています。

使い方の例

  • 「APIにJWT認証とリフレッシュトークンの更新処理を追加して」
  • 「管理者だけが使えるエンドポイントを設定し、権限テストも作って」
  • 「サービス間通信用のAPIキー認証を実装して」

注意点

原文では、Claude Code向けのスキルとされています。実装には暗号ライブラリ、安全な秘密情報の保管先、認証情報やトークンを保存するデータベース、パスワードハッシュ化ライブラリが必要です。外部プロバイダー認証を使う場合はOAuth 2.0の認証情報も必要です。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(4)

  • SKILL.md5.8 KB
  • references/errors.md1.0 KB
  • references/examples.md6.5 KB
  • references/implementation.md1.5 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Building API Authentication

Overview

Build secure API authentication systems supporting JWT Bearer tokens, OAuth 2.0 authorization code and client credentials flows, API key management, and session-based authentication. Implement token issuance, validation, refresh rotation, revocation, and role-based access control (RBAC) with scoped permissions across all API endpoints.

Prerequisites

  • Cryptographic library: jsonwebtoken (Node.js), PyJWT (Python), or jjwt (Java)
  • Secure secret storage: environment variables, AWS Secrets Manager, or HashiCorp Vault for JWT signing keys
  • Database table for user credentials, refresh tokens, and API key storage
  • Bcrypt or Argon2 for password hashing (never store plaintext passwords)
  • OAuth 2.0 provider credentials for third-party auth integration (Google, GitHub, Auth0)

Instructions

  1. Examine existing authentication setup using Grep and Read, identifying current auth mechanisms, middleware placement, and any endpoints bypassing authentication.
  2. Implement JWT token issuance on successful login: sign with RS256 (asymmetric) or HS256 (symmetric), including sub (user ID), iat, exp (15-minute access token), roles, and scopes in the payload.
  3. Create authentication middleware that extracts the Bearer token from the Authorization header, verifies the signature and expiration, and injects the decoded user context into the request object.
  4. Implement refresh token rotation: issue a long-lived refresh token (30 days) alongside the access token, store a hash of the refresh token in the database, and rotate on each refresh (invalidating the previous token).
  5. Build role-based access control (RBAC) middleware that checks user.roles against endpoint-required roles, supporting both role-level (admin, user) and scope-level (read:users, write:orders) authorization.
  6. Add API key authentication as an alternative to JWT for machine-to-machine communication: generate cryptographically random keys, store hashed values, and validate against the X-API-Key header.
  7. Implement OAuth 2.0 client credentials flow for service-to-service authentication, with token caching and automatic renewal before expiration.
  8. Add brute-force protection on login endpoints: rate limit to 5 attempts per minute per IP, implement progressive lockout (15 min, 1 hour) after repeated failures, and log all authentication attempts.
  9. Write security tests covering: valid/invalid/expired tokens, refresh token rotation, role enforcement, API key validation, brute-force lockout, and token revocation.

See references/implementation.md for the full implementation guide.

Output

  • ${CLAUDE_SKILL_DIR}/src/auth/jwt.js - JWT token issuance, verification, and refresh logic
  • ${CLAUDE_SKILL_DIR}/src/auth/middleware.js - Bearer token authentication middleware
  • ${CLAUDE_SKILL_DIR}/src/auth/rbac.js - Role-based and scope-based access control middleware
  • ${CLAUDE_SKILL_DIR}/src/auth/api-keys.js - API key generation, hashing, and validation
  • ${CLAUDE_SKILL_DIR}/src/auth/oauth.js - OAuth 2.0 flow implementations
  • ${CLAUDE_SKILL_DIR}/src/routes/auth.js - Login, register, refresh, and logout endpoints
  • ${CLAUDE_SKILL_DIR}/tests/auth/ - Authentication and authorization security tests

Error Handling

ErrorCauseSolution
401 Token ExpiredJWT exp claim is in the pastClient should attempt token refresh; if refresh fails, redirect to login
401 Invalid SignatureJWT signed with different key or tampered payloadVerify signing key matches between issuance and validation; check for key rotation issues
403 Insufficient ScopeAuthenticated user lacks required role/scope for endpointReturn required scope in error body; log authorization failure with user and endpoint details
Refresh token reusePreviously rotated refresh token used (possible token theft)Invalidate all user sessions immediately; alert user of potential compromise; require re-authentication
API key leakedAPI key exposed in client-side code, logs, or version controlRevoke compromised key immediately; issue replacement; scan for exposure source

Refer to references/errors.md for comprehensive error patterns.

Examples

JWT with refresh rotation: Login returns {accessToken (15min), refreshToken (30d)}; client stores refresh token securely; on 401, client calls POST /auth/refresh with old refresh token, receives new pair, old refresh token is invalidated.

Multi-provider OAuth: Support "Sign in with Google" and "Sign in with GitHub" using OAuth 2.0 authorization code flow, creating local user accounts on first sign-in and linking subsequent provider connections.

API key with scoped permissions: Generate API keys with specific scopes (read:analytics, write:webhooks), stored as SHA-256 hashes, displayed to the user only once at creation, with key rotation support.

See references/examples.md for additional examples.

Resources

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

abridge-ci-integration

無料概要あり

Abridge連携コードのCIに合成データを使った回帰チェックを加え、同意状態、ノート確認、ログの秘匿、ロールバックなど顧客側の処理を検証します。

  • Abridge連携の回帰テストを追加したいとき
  • 同意やノート確認の処理を検証したいとき
  • ログに機微情報が出ないか確かめたいとき
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-common-errors

無料概要あり

Abridgeの録音、記録の確認、Epicへの引き渡し、アクセスの不具合を観測情報から切り分け、患者情報を抑えた証拠と担当窓口への引き継ぎ資料を整理するスキル。

  • 録音とアップロード障害の切り分け
  • 記録生成の遅延や編集画面の不具合調査
  • Epic連携障害の担当窓口の特定
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-core-workflow-a

無料概要あり

同意確認から録音、生成メモの根拠確認、編集、最終確定まで、臨床文書作成の手順と確認ポイントを整理するスキルです。

  • 診療メモ作成の手順を導入・監査したいとき
  • 同意から医師の確認までの流れを整理したいとき
  • 下書きの根拠確認と停止条件を定めたいとき
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-core-workflow-b

無料概要あり

Abridgeで臨床家が確認した記録内容が、承認済みの手順でEpicの適切なテンプレート欄へ渡るか、テスト記録を使って対応関係や例外を検証するスキルです。

  • AbridgeとEpicの記録欄の対応を確認したいとき
  • 部門ごとの連携設定を監査したいとき
  • 承認済みテスト記録で連携を検証したいとき
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-cost-tuning

無料概要あり

Abridgeの導入・更新判断に向け、利用定着率や業務の完了状況、診療記録の品質、支援負担を契約に基づく費用情報と照らし、継続や改善の選択肢を整理するスキル。

  • Abridge導入後の定着率確認
  • 契約更新の判断材料をまとめたいとき
  • 診療環境ごとの業務成果の比較
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-debug-bundle

無料概要あり

Abridgeの障害調査で、録音や診療記録を含めず、許可した項目だけを集めたサポート用資料と確認用マニフェストを作成します。

  • 障害サポート用の証拠をまとめたいとき
  • 共有資料の除外項目を記録したいとき
  • 調査情報を安全な経路で引き継ぎたいとき
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

jeremylongshore のスキルをすべて見る

このスキルの問題を報告する