以前の記事「Cognito + Google OAuthで詰まる3つの罠」を書いてから、しばらく時間が経ちました。あの記事は「詰まった話」でしたが、今回はその続きの「完成した話」です。
📌 AI時事ネタ：大企業では当たり前のSSO——中小企業との導入格差が広がっている
大手の開発現場では、社内システムへのログインが軒並みOkta経由になっている光景をよく目にします。Oktaは2026年時点で世界26,000社超が導入し、SSO市場のシェア約34%を握る最大手です。Okta「Businesses at Work 2025」レポートによると、MFA(多要素認証)の企業導入率はグローバルで70%に達しており、従業員1万人超の大企業では87%が導入済みです。一方、中小企業の導入率は34%前後にとどまっており、規模による差が大きい状況です。
一方で、SSOが普及するほど「SSOが突破された時のダメージ」も大きくなっています。2025年には67%のサイバーセキュリティインシデントがIDや認証情報の侵害から始まったと報告されており、OracleのSSO基盤が侵害されて14万社超が影響を受けた事案も発生しました。技術的な原因は「2021年に修正パッチが公開済みの既知の脆弱性(CVE-2021-35587)が、4年間放置されたまま本番稼働していた」という管理上の手抜かりです。設計そのものが破られたわけではなく、レガシーシステムへのパッチ適用を怠っていたことが原因です。大手ベンダーも古いシステムを使い続ける限りリスクは同じ、という教訓です。
だったら自分で作れるんじゃないか
以前いた現場ではOkta専任のエンジニアがいました。「Oktaって結局APIを叩いているだけでは？」と思いながら眺めていたのですが、彼らはそれなりに重宝されていました。SSOまわりは設定の組み合わせが複雑で、属人化しやすいのは確かです。ただ、それを見ながら「自分でSSO認証そのものを作ってみたい」という気持ちが芽生えたのも事実です。今回のkitは、ある意味そのリベンジかもしれません。
「詰まった話」の続き——今度は完成しました
以前の記事「Cognito + Google OAuthで詰まる3つの罠」では、属性マッピング・CloudFront Functionsのランタイム仕様変更・redirect_uriのスラッシュ1文字の差、という3つのハマりポイントを書きました。
あの記事はいわば「序章」でした。その後も詰まりに詰まりながら、ようやくSSO認証kitとして完成形が見えてきました。今回はその全貌を書きます。
そもそもSSOとは——SAMLとOIDCの違いから整理する
「SSO(シングルサインオン)」という言葉は知っていても、裏側で何が動いているかを知っている人は意外と少ないです。技術多めになりますが、ここは読んでおいて損はないと思います。
SSOを実現する規格は大きく2種類あります。SAMLとOAuth 2.0 + OpenID Connect(OIDC)です。
SAMLとは
SAML(Security Assertion Markup Language)は、主に大企業・官公庁のシステム間連携で使われる古参の認証規格です。Okta・Active Directory FSといったエンタープライズ製品がSAMLに対応しており、「会社のシステムに一度ログインすれば他の業務システムにも自動でログインできる」という大企業の社内SSO基盤を支えています。
技術的には認証・属性・認可の情報をXMLで一括送信するオールインワン設計です。XMLは情報量が多く1件5〜10KBほどになります。
OAuth 2.0 + OpenID Connect(OIDC)とは
一方、GoogleログインやLINEログインなど、一般消費者向けのSNSログインの裏側で動いているのがOAuth 2.0 + OIDCです。
OAuth 2.0が「認可(何をしていいか)」を担当し、その上にOIDC(OpenID Connect)が「認証(誰であるか)」のレイヤーを追加した設計です。情報はJWT(JSON Web Token)というコンパクトなJSON形式で扱われ、SAMLのXMLと比べてサイズは10〜50分の1程度です。
さらにSPA(シングルページアプリケーション)で安全に使うためにPKCE(Proof Key for Code Exchange)という拡張も使っています。PKCEは「認可コードを横取りされても悪用できないようにする」仕組みで、OAuth 2.1では必須化される方向です。
今回OIDCを選んだ理由
| SAML | OAuth 2.0 + OIDC | |
|---|---|---|
| 主な用途 | 大企業B2B・社内システム連携 | 一般消費者向けSNSログイン・SPA |
| 形式 | XML(重い) | JWT(軽い・コンパクト) |
| モバイル・SPA | 相性が悪い | 相性が良い |
| SNSログイン対応 | 難しい | 標準対応 |
| 個人開発・スタートアップ | オーバースペック | 最適 |
一般ユーザーが使うWebアプリにGoogleログインを組み込むなら、OIDCが自然な選択です。SAMLはエンタープライズの既存レガシー基盤と繋ぐ場面で力を発揮します。「中小企業・スタートアップが新規でWebアプリを作る」用途なら、OIDCで十分です。
なぜGmailとemail認証だけ？——他のSSOプロバイダーを辞退した理由
「GoogleとAmazon、Apple、LINE、Azure ADも対応してほしい」と思われる方もいるかもしれません。ただし、2026年6月現在、マンチーが個人開発レベルで対応したのはGoogleアカウントとメールアドレス+パスワード認証の2種類のみです。
他のプロバイダーを見送った理由を正直に書きます。
Amazon(Sign in with Amazon)
AWSのサービスではありますが、Sign in with Amazonは開発者登録と審査が必要です。さらに利用規約上「Amazonのブランドガイドラインに従ったUI実装」が求められ、デザイン面での制約もあります。個人開発の小規模運用には手続きコストが見合いませんでした。
Apple(Sign in with Apple)
Appleは「サードパーティログインを実装するなら、Sign in with Appleも必ず実装すること」というApp Storeポリシーがあります。Webアプリ単体なら必須ではありませんが、将来的にiOSアプリ化する場合は必須になります。また、Apple Developer Programへの年間加入費(約1万3,000円)が必要です。さらにAppleはユーザーのメールアドレスを隠蔽する「メールリレー機能」を持っており、実際のメールアドレスが取得できないケースへの対応設計が別途必要になります。
LINE(LINEログイン)
LINEログインはLINE Developersへの事業者登録と、利用規約上の審査があります。また月間アクティブユーザー数によっては費用が発生する場合があります。日本国内の利用者には非常に有効なプロバイダーですが、今回のkit対象は法人・中小企業向けが主なため、優先度を下げました。
Azure AD(Microsoft)
Microsoftアカウントでのログインは、Azure Active Directoryのテナント設定と、場合によってはAzure AD B2Cの費用が発生します。B2Cは月間アクティブユーザー50,000人まで無料ですが、設定の複雑さと、エンタープライズ色が強い対象との兼ね合いから今回は見送りました。
これらのプロバイダーは技術的に対応できないわけではありません。kit化の思想として「必要な時に追加できる設計」にしています。Cognito自体がSAMLも含めた複数のIdPに対応しているため、後から追加するのは比較的スムーズです。
前回の記事では語れなかった——もう3つの苦労話
「Cognito + Google OAuthで詰まる3つの罠」では書き切れなかった、追加の苦労ポイントです。
苦労その1：メール認証が「動いていない」ことに気づかなかった
Cognitoのメール+パスワード認証を実装した後、「メール確認コードが届く仕組みです」と説明しながら、実際には確認コードなしで即ログインできる状態になっていました。
原因はCognitoの「属性検証・自動送信」設定が「メッセージを自動的に送信しない」になっていたことです。設定画面には確かに項目がありますが、デフォルト値が「送信しない」なのを見落としていました。
実際に自分で新規登録フローを踏んで初めて発覚。「実装した」と「正しく動いている」は別の話です。認証系は必ず全フローを実際に通してテストすることが鉄則だと痛感しました。
苦労その2：Pre-Token Generation Lambdaの設計
ログインのたびにJWTトークンに「このユーザーは有効か・どのプランか・期限が切れていないか」を動的に書き込む処理をPre-Token Generation Lambda(Pythonで実装)で実現しています。
Lambda(AWSのサーバーレス実行環境・イベント発生時だけ動く)がCognito認証の直前に呼ばれ、DynamoDB(AWSのNoSQLデータベース)からユーザー情報を取得してJWTのカスタムクレーム(属性情報)を書き込む設計です。
この処理のタイムアウト設定・エラーハンドリング・DynamoDBへのIAM権限付与の組み合わせで何度もハマりました。特にIAMロール(AWSのアクセス権限管理)の設定ミスは、エラーメッセージが「Access Denied」の一行しか出ないため原因特定に時間がかかりました。
苦労その3：SES経由メールの文字化け
招待メール・期限切れ通知メールをAWS SES(Simple Email Service・メール送信サービス)経由で送信する実装で、日本語本文が「=1B$B%F%9%H…」のような文字化けで届く問題が発生しました。
原因はRFC2822形式のメール全文の中で、Content-TypeとContent-Transfer-Encodingのヘッダーが期待した位置に来なかったことです。Quoted-Printableというエンコード方式のデコードがスキップされていました。対処はフォールバック処理の追加で解決しましたが、「メールが届く」と「文字化けしていない」は別の確認事項だと学びました。
3つの規約・NDA——認証基盤には法的整備もセットで必要
SSOを実装するということは、ユーザーのメールアドレス・氏名・SNSのサブID(識別子)を取得・保管することを意味します。これは個人情報保護法の対象です。
マンチーは認証基盤の完成と並行して、3つの法的ドキュメントを整備しました。
1. プライバシーポリシー
取得する個人情報の種類・利用目的・第三者提供の有無・開示請求への対応方法を明記します。Googleログインを実装した時点で、Googleから取得するメールアドレス・名前・sub(識別子)が個人情報として記録されます。「テスト中だから後で」は通用しません。
2. 利用規約
サービスの利用条件・禁止事項・サービス変更や停止の場合の取り扱い・免責事項を定めます。個人開発でも「利用規約がない=野放し」は法的に無防備な状態です。
3. NDA(秘密保持契約)
テスター・パイロット顧客に試用してもらう段階では、まだ未公開の機能や設計情報を見せることになります。「見た情報を外に出さない」合意をデジタル署名で取る仕組みをkit内に実装しました。サービス申込フロー内でNDA同意→DynamoDBへの署名記録まで自動化しています。
これらを「あとから整備」ではなく「kit内に組み込んだ形で提供」できるのが、このkitの特徴のひとつです。
AWS + Claudeの組み合わせが最高だった
個人開発でこの規模の認証基盤を作ることができたのは、AWSとClaudeの組み合わせがあったからです。
AWS側はCognito・Lambda・CloudFront Functions・SES・DynamoDB・IAMというサービス群が密に連携しており、認証基盤に必要な要素がほぼ揃っています。一方でドキュメントが膨大・分散していて、単独で学習するのは相当な時間がかかります。
そこでClaudeが威力を発揮しました。AWSのドキュメントを日本語で要約・解説してもらい、英語コミュニティ(AWS re:Post)の技術情報を取り込みながら実装を進められました。IAMポリシーの記述・Lambdaのエラーハンドリング・CloudFront Functionsのランタイム仕様確認——こうした「調べるだけで半日かかる作業」がセッション内で完結します。
正直なところ、Claudeがいなければこのkitは完成しなかったと思います。「AIに丸投げ」ではなく、「人間が設計判断をしてAIが実装を支援する」という分業が今回も機能しました。
kitとしての設計思想——Webアプリの前に置くだけ
このSSO認証kitの核心的な設計は「既存のWebアプリを改造しない」という点です。
認証レイヤーはCloudFront(AWSのCDN・コンテンツ配信ネットワーク)の前段に置かれており、Webアプリ本体には一切手を加えません。アプリ側は「認証が通ったリクエストだけが届く」状態になるだけです。
[ユーザー]
↓
[CloudFront + CloudFront Functions(Cookie認証)]
↓ 認証済みのみ通過
[Cognito Hosted UI(ログイン画面)]
↓
[Pre-Token Generation Lambda(期限・プラン判定)]
↓
[あなたのWebアプリ(S3 or EC2 or 任意)]この設計により、「新しいWebアプリを作るたびにゼロから認証を実装する」という手間がなくなります。kitを前に置くだけで、どんなWebアプリにも招待制アクセス管理・期限管理・ユーザー管理が付きます。
中小企業・スタートアップへ——導入に二の足を踏んでいる方へ
認証基盤の構築は「やりたいけど、工数とコストが…」で後回しにされがちです。Auth0やFirebase Authenticationといったサービスも選択肢としてありますが、月額課金が発生し、ユーザー数が増えると費用も増えます。
このkitはAWSのCloudFront・Cognito・Lambdaを基盤にしており、月間アクティブユーザー50,000人まではCognitoが無料、CloudFrontも月100万リクエストまで無料枠があります。中小企業の社内ツール・スタートアップの初期運用であれば、月数百円以下で本格的な認証基盤が動きます。
「大企業だけが持てるものを、中小企業やスタートアップにも手の届くコストで」——これがこのkitの開発動機でもあります。
まとめ
SSO認証kitの完成まで、想定以上の時間とトラブルがありました。でも振り返ると、ひとつひとつのトラブルが「こういう設計にすべきだった」という気づきになっており、それがkitの完成度に繋がっています。
技術的なハードルよりも、「法的整備・規約・NDA」が意外と重かったという実感があります。認証を実装した瞬間から個人情報を扱う事業者になる——その認識を持って設計することが、個人開発者にとって今一番大事なことだと感じています。
関連記事もどうぞ：
コメント