JWT

個人開発アプリの認証は「絶対に」WorkOS を使え — MCP 化で知った最強の選択肢 では、WorkOS AuthKit の Dynamic Client Registration（DCR）対応が MCP 認証の決め手になる、という話を書いた。 MCP × OAuth 2.1 の全体像は MCP のセキュリティが OAuth 2.1 で大幅進化 で扱った。本記事はその中で SHOULD/MAY 扱いされている DCR を仕様レベルで深掘りする補足記事だ。 具体的には、DCR を定義する RFC 7591 そのものの仕様と、MCP 認証で必ず連動する周辺 RFC 群（9728 / 8414 / 9068 / 8707 / 7636）の関係 を、Claude Code の自動ログインフローを追いながら整理する。 この記事でわかること: なぜ事前登録なしにクライアントが認可サーバーに繋がってくるのか（RFC 7591 / 9728 / 8414 の連動） Claude Code の自動ログインフローを HTTP リクエスト単位で何が起きているか なぜ JWT の audience 検証で詰まるのか（RFC 9068 / 8707 と DCR の構造的な相性問題） なぜ MCP では Dynamic Client Registration（DCR）が必要なのか 従来の OAuth 2.0（RFC 6749）は、クライアント（アプリ）を事前に手動登録する 前提だった。Google や GitHub の OAuth を使うときに、開発者が「アプリを登録 → client_id と client_secret を発行 → コードに埋め込み」という流れだ。 ...

個人開発アプリを MCP 化しようとして、認証の壁に阻まれた経験はないだろうか。 大手 SaaS が次々と MCP を公開する今、個人開発者も「自分のアプリを MCP で叩けるようにしたい」と思うのは自然な流れだ。 しかし認証の設計は想像以上に重い。 この記事では、WorkOS AuthKit を使えば MCP 認証（OAuth 2.0 Dynamic Client Registration 対応）を Next.js で 30 分・50 行以内に実装できる理由と具体的な手順を紹介する。 MCP 化の波が押し寄せている ここ数ヶ月で、Notion・Linear・Stripe・Vercel・Cloudflare など、ちょっと触っているサービスはほぼ間違いなく MCP を出している印象だ。 Claude Code や Cursor に登録すれば、「自分の Notion を読んで」「Linear に issue を立てて」が自然言語で動く。 個人開発者にとっても無視できない流れだ。 自分の作ったアプリも、CLI だけじゃなく MCP で叩けるようにしておくと、ユーザー体験が一段別物になる。 認証の壁 いざ自作アプリを MCP 化しようとすると、ほぼ全員がここで止まる。 「Bearer トークンを受け取って検証する」と書くと一行だが、実際には： ユーザーごとにアクセストークンを発行する仕組み Claude Code などのクライアント側がトークンをどう取得するか（OAuth？API キー手動コピペ？） トークンをどう保存・更新するか（リフレッシュトークン、有効期限…） 複数クライアントから同じユーザーが繋ぐ場合の扱い これを真面目に作ると、週末が溶ける。筆者（html-to-pptx 作者）も最初は自前で API キー方式を実装していたが、「MCP クライアントから自動でログインさせたい」と思った瞬間、設計が一気に重くなることに気づいた。 結論：WorkOS（AuthKit）を使え タイトルにも書いたが、もう一度言う。個人開発者が MCP 化するなら、WorkOS の AuthKit 一択だ。 B2B 向けのサービス展開を考えている場合も、その場合も WorkOS が特におすすめだ。 ...

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（アルゴリズム混同攻撃）と同様の攻撃を再び可能にする。前回の修正が不完全だったことが根本原因だ。 ...