認証

gh（GitHub CLI）は通常、gh auth login の対話的なブラウザフローで認証します。しかし CI/CD パイプライン、共有サーバー、使い捨てコンテナのような ブラウザもキーボード入力もない環境 では、その対話フローは使えません。 こうした「ヘッドレス（非対話）」環境では、アクセストークン（パーソナルアクセストークンなど）を環境変数で渡す ことでクローンを自動化できます。本記事では、推奨される認証パターンと、その際に陥りがちな落とし穴・セキュリティ上の注意点を整理します。 なお、本記事を書く過程で「gh auth token --web でトークン生成画面を開ける」という情報を検証したところ、そのようなフラグは存在しませんでした。よくある誤情報なので、後半で正しい代替手段とあわせて解説します。 方法1：環境変数 GH_TOKEN を使う（最もおすすめ） gh は、環境変数 GH_TOKEN（または GITHUB_TOKEN）にトークンが設定されていると、それを自動的に認証に使用します。gh auth login のような状態の保存を一切行わないため、自動化環境に最も適しています。 一時的にトークンを渡してクローンする場合は、1 行で実行できます。 1 GH_TOKEN=ghp_YourTokenHere gh repo clone owner/repo gh auth login --help のドキュメントにも、 Alternatively, gh will use the authentication token found in environment variables. This method is most suitable for “headless” use of gh such as in automation. と明記されており、自動化での利用は GH_TOKEN が公式推奨です。 ...

HubSpot は API 認証の選択肢が多く、「結局どれを使えばいいのか」が混乱しがちです。特に Claude Code から HubSpot を操作したい場合、現在は 6 種類の認証手段が併存しています: 非公開アプリ（Private App） 旧 API キー（廃止済み） MCP 認証アプリ（HubSpot 公式 MCP Server） パーソナルアクセスキー（Personal Access Key） 開発者 API キー（Developer API Key） サービスキー（Service Key、新規 Beta） この記事では、それぞれの違い・推奨用途・Claude Code から使う場合の選び方を整理します。なお旧 API Key は廃止済みですが、参考情報として記事末尾で触れます（実質的な選択肢は 6 つです）。 結論を先に言うと: 用途で 2 軸に分かれます。 アドホックに自然言語で操作したい（営業・マーケが Claude Code から HubSpot を触る等） → 公式 MCP サーバー 本番運用・バッチ・Webhook など継続的なシステム統合 → REST API 直叩き + Service Key（新規）/ Private App（既存） 両者は競合ではなく補完関係で、実務では併用するのが現実解です。 早見表 認証方式 用途 スコープ トークン寿命 状態 Claude Code から使うなら HubSpot MCP Server（公式） AI エージェントから HubSpot 操作 アプリと同等 OAuth ベース ✅ 2025-2026 リリース ✅ 最も推奨（1 行で接続） Service Key（新） システム間データ連携 アカウント単位の細かい権限 永続 ✅ 2026-02-10 Public Beta ✅ Private App の後継、新規ならこれ Private App 単一アカウント向け統合 アプリ単位で細かく設定 永続 ⚠️ 維持されているが、新規は Service Key 推奨 ✅ シンプルな REST 呼び出し OAuth 2.0（Public App） Marketplace アプリ・複数アカウント scope ベース access 30 分・refresh で更新 ✅ 公式・現役（v3 が新版） △ 自前で OAuth フロー実装が必要 Personal Access Key（PAK） HubSpot CLI 認証 アカウントごと 永続（rotate 可能） ✅ 現役 △ CLI 経由の操作のみ Developer API Key Developer Account 内のアプリ管理 開発者アカウント全体 永続 ✅ 現役 △ アプリ管理用、CRM データには不向き 旧 API Key（参考） 単純な API 呼び出し アカウント全体 永続 ❌ 2022-11-30 廃止 ❌ 使えない 各認証方式の詳細 ① 旧 API Key（廃止済み、参考情報） HubSpot ポータルの「Integrations → API Key」から発行できたアカウント単位の単一キー。 ...

JWT 認証ライブラリ fast-jwt に重大な脆弱性が発見された。公開鍵の先頭に空白文字や改行があるだけで認証が突破される可能性があり、影響はバージョン 6.1.0 以下に及ぶ。 fast-jwt とは fast-jwt は Node.js 向けの高速な JWT（JSON Web Token）の署名・検証ライブラリ。パフォーマンスを重視した実装で広く利用されているが、今回その内部の文字列処理と正規表現の甘さが致命的な脆弱性につながった。 CVE-2026-34950: 空白文字による認証バイパス 問題の概要 CVSS スコア 9.1（Critical） の深刻な脆弱性。公開鍵の検証に使われている正規表現が、文字列の先頭を厳密に検証していないという欠陥に起因する。 攻撃メカニズム 公開鍵の先頭にスペースや改行文字（\n）が含まれると、正規表現による公開鍵の検証が失敗する。その結果、公開鍵が HMAC 用の秘密鍵として誤って扱われ、攻撃者は任意のトークンを署名できてしまう。 1 2 3 4 5 6 7 8 9 // 通常の公開鍵（検証成功） -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY----- // 先頭に空白が入った場合（検証失敗 → HMAC 鍵として扱われる） -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY----- これは過去に修正されたはずの CVE-2023-48223（アルゴリズム混同攻撃）と同様の攻撃を再び可能にする。前回の修正が不完全だったことが根本原因だ。 ...

概要 パスワード認証は秘密そのものをネットワーク送信するため本質的に脆弱。FIDO2 は秘密鍵をデバイス内（TPM・Secure Enclave）に保管し、署名のみ送信。チャレンジ・レスポンス方式でリプレイ攻撃不可能。 3層フィッシング防御 ブラウザがオリジン情報を認証器に伝達 認証器がドメイン一致を検証 サーバーがオリジン情報を最終検証 普及状況 Google 8億+アカウント、Amazon 1.75億人が利用。日本証券業協会が OTP を非推奨化しパスキー推奨。楽天証券・SMBC 日興証券が導入。 関連ページ メール認証（SPF/DKIM/DMARC） — 別のなりすまし防止技術