②【SSO認証キット】オーセンティケーター(Authenticator)を導入した話｜アプリごとにON・OFFできる二段階認証

SSO(一度のログインで複数のサービスを使える仕組み)の認証kitを作って、「これでログインまわりは一段落」と思っていました。ただ、ひとつ気になっていたことがあります。SSOは「ログインできる人」を絞る仕組みですが、「いまログインしているのが本当にその本人か」までは保証してくれない、ということです。パスワードやGoogleアカウントが誰かに知られてしまえば、その人は本人としてそのまま入ってこられます。

そこで今回、このkitにオーセンティケーター(英語ではAuthenticator。スマホのアプリに表示される6桁のコードで本人確認する認証アプリ。Google Authenticatorなどが代表例です)を導入しました。結果から言うと、管理画面のログインにオーセンティケーターによる二段階認証を組み込み、さらに「アプリごとにON・OFFを切り替えられる」ところまで形になっています。今回は、その中身を順番に書きます。

現場では、いまオーセンティケーターを使っているケースが本当に多い

最初に、なぜオーセンティケーターを選んだのかを書いておきます。マンチーが入っている現場でも、いま二段階認証にオーセンティケーターを使っているケースは本当に多くなりました。スマホのアプリを開いて6桁のコードを入力する場面は、本当によく見かけます。

数字でも、その傾向は裏付けられています。米国の消費者団体Consumer Reportsの調査によると、二段階認証を使っている米国の成人のうち、認証アプリを使っている人は、2024年5月の50%から2025年5月には55%に増えたと報じられています。一方、Oktaの「Secure Sign-in Trends Report 2025」では、企業の従業員がSMSで認証する割合は、1年間で17.5%から15.3%に下がったとされています。SMSが少しずつ減って、アプリやパスキーといった別の方式に移っている様子がうかがえます。

なお、企業の現場で「認証アプリ方式が何割」という形の最新の公的な数字は、残念ながら見つけられませんでした。ここでは、利用者調査の数字と、マンチーが現場で見ている実感を合わせて書いています。

SMSの認証は、スマホの電話番号を乗っ取られる攻撃(SIMスワップなど)に弱いことが知られています。オーセンティケーターは、電話番号ではなく端末の中にある鍵でコードを作るので、その手の攻撃には強い、というのが乗り換えが進む理由のひとつです。また、SMSは送信経路が複雑で、通信事業者をはじめ、さまざまな事業者が間に入り組んで関わっています。そのため、マンチーは個人的にはSMS認証をおすすめしません。導入のハードルも低く、アプリは無料で、サーバー側にSMSの送信費用もかかりません。個人開発のkitに入れる二段階認証として、ちょうどいい選択だと考えました。

📌 AI時事ネタ：認証情報の悪用は減った？——数字の裏を読む

2026年5月に公開されたVerizonの「データ侵害調査報告書(DBIR)」2026年版では、侵害の最初の入口として最も多かったのは脆弱性の悪用で31%、盗まれた・悪用された認証情報は13%だったと報じられています。前年の22%から大きく下がったように見えますが、この年から「なりすまし(口実を作って相手を騙す手口)」を別の項目として数えるようになったため、その分が認証情報の項目から移っていることが一因とされています。実際、攻撃の途中のどこかの段階で認証情報が使われていたケースまで含めると、39%の侵害に関わっていたとのことです。

もう一つ気になったのが、クラウド環境の管理者アカウントについての数字です。報道によると、調査対象の37%の組織で、クラウド基盤の管理者アカウントに二要素認証が無効のままのものがあったそうです。

「入口としては減った」という見出しの数字だけを見ると安心しそうになりますが、中身を見ると、認証情報は攻撃のいろいろな場面で使われ続けていて、管理者アカウントの守りが甘い組織も少なくありません。個人開発であっても、管理画面だけはきちんと固めておく価値があると、あらためて思いました。

国内に目を向けても、個人情報の漏えい事故が相次いでいます。ScanNetSecurityの報道によると、2025年の上場企業の個人情報漏えい・紛失事故は180件、漏えいした人数は約3,063万人分で、前年から約93%増えたとされています。100万人以上の大型事故は6件で、前年の2件から3倍に増えました。原因別では、ウイルス感染・不正アクセスが116件(64.4%)と最も多くなっています。

直近でも、9月末には、あるサービスで退会済みの会員を含む約660万件の情報(運転免許証の画像を含む)が流出した可能性があると報じられました。10月に入ってからも、大手の金融機関で、業務を委託していた外部の会社のサーバーが不正アクセスを受け、約11万人分の氏名やメールアドレスなどが漏れた可能性があると発表されています。

ただし、こうした事故は、必ずしも認証を突破された手口によるものではありません。委託先のサーバーに侵入されたケースもあり、ログインの二段階認証だけで防げる話ではないのが実情です。それでも、IDやパスワードが漏れたときに、それだけでは中に入れないようにしておく備えは、やはり必要だとマンチーは考えています。

今回導入したもの：管理画面ログインへのオーセンティケーター

仕組みは、オーセンティケーターでよく使われるTOTPという方式です。スマホにGoogle AuthenticatorやAuthyといったアプリを入れておくと、30秒ごとに切り替わる6桁のコードが表示されます。ログインのあとにこのコードを入力して、初めて先に進める、という流れです。パスワードやGoogleアカウントの情報が漏れても、スマホの中のアプリがなければ入れません。

導入したのは、このkitの管理画面です。管理画面は、ユーザーの一覧や編集、メール送信など、触れれば全ユーザーの情報に手が届いてしまう、いちばん守りたい場所です。ここのログインに、オーセンティケーターによる二段階認証を挟みました。

オーセンティケーターでログインするまでの流れ

管理画面にログインしてから中に入るまでの流れは、次のようになっています。

1. 「Googleでログイン」を押して、まずGoogleアカウントで通常のログインをします。

2. ログインした人が管理者の権限を持っているかを確認します。一般ユーザーなら、ここで「アクセス権限がありません」の画面になり、先には進めません。

3. 管理者であれば、次に「この管理画面で二段階認証が必須に設定されているか」を確認します。

4. 必須の設定になっている場合、オーセンティケーターをすでに登録済みかどうかで、画面が分かれます。

5. 登録済みなら、6桁のコードを入力する画面が出ます。コードが合えば、管理画面に入れます。

6. 未登録なら、そのまま登録画面に進みます(次の章で説明します)。

6桁のコードの入力欄には、いくつか使いやすさの工夫を入れています。スマホで開いたときに数字キーボードが出るようにし、数字以外を打っても自動で取り除かれます。コードが違ったときは、入力欄を空にして、すぐ打ち直せる状態に戻します。

一度コードを通したあとは、同じブラウザのタブを開いている間は、再度の入力を求めません。作業のたびにコードを聞かれ続けないようにしています。

オーセンティケーターの初回登録の流れ

オーセンティケーターをまだ登録していない管理者が初めてログインすると、画面の上に「認証アプリを設定してください」というポップアップが重なって表示されます。手順は画面の中に4ステップで書いてあります。

1. Google AuthenticatorやAuthyなどを、スマホにインストールする

2. アプリの「＋」から「QRコードをスキャン」を選ぶ

3. 画面のQRコードを読み取る

4. アプリに表示された6桁のコードを入力して「設定完了」を押す

これで登録が完了し、次回のログインからは、毎回コードの入力が必要になります。

登録画面には、ひとつ細かい配慮を入れています。QRコードを読み取れない環境(PCだけで作業している場合など)でも登録できるように、QRコードの下に「認証アプリで開く」リンクと、シークレットキー(登録に使う文字列)のテキスト表示も並べました。カメラが使えなくても、キーを手で入力すれば、同じように登録できます。

アプリごとにオーセンティケーターの必須・不要を切り替えられる

今回いちばん意識したのは、二段階認証を一律に強制せず、運用側が切り替えられるようにしたことです。管理画面の中に「アプリ別 MFA(認証アプリ)設定」というパネルを用意しました。このkitでつないでいるアプリが一覧で並び、アプリごとに「ON(必須)」と「OFF」のスイッチがあります。ONにすると、そのアプリにログインするユーザーは、オーセンティケーターが必要になります。

SSOの認証kitは、複数のWebアプリの前に置いて使う想定です。守るべき情報の重さは、アプリごとに違います。触れれば全体に影響が出る管理画面と、気軽に試してもらいたいアプリとでは、求めたい強度が違います。それを、アプリごとに運用しながら調整できるようにした、というわけです。

スイッチを切り替えようとすると、「このアプリのMFAをONにします。よろしいですか？」という確認のダイアログが出ます。スイッチは1アプリずつ、確認を挟んで切り替える作りです。管理画面自体のオーセンティケーターも、この同じスイッチで切り替わります。

オーセンティケーターをなくしたときは

二段階認証で必ず出てくる問題が、「スマホをなくした」「機種変更した」ときです。コードを入力する画面の下には、「認証アプリを紛失した場合は管理者に連絡してください」という案内を出しています。管理者に連絡してもらう、という前提の設計です。

正直に書いておく、オーセンティケーターの限界

ここまで書いてきましたが、オーセンティケーターが万能というわけではありません。6桁のコードは、本物そっくりに作られた偽のログイン画面にだまされて入力してしまうと、そのまま攻撃者に使われてしまう可能性があります。コードを入力する「人」がだまされる攻撃には、強くないのです。

この弱点を克服するのが、パスキーやセキュリティキーといった、偽サイトでは動作しない「フィッシング耐性」のある認証方式です。Oktaの「Secure Sign-in Trends Report 2025」によると、こうしたフィッシング耐性のある認証を使うユーザーの割合は、2024年1月の8.6%から2025年1月には14.0%へと、1年で約6割増えたとされています。それでも全体から見れば、まだ少数派です。

つまり、オーセンティケーターは「パスワードだけ」よりはるかに安全で、導入のハードルも低い、現実的な第一歩です。そのうえで、次の候補としてパスキー対応がある、というのが今のところの整理です。

中小企業・個人開発者のみなさんへ

大企業ではあたりまえになっている二段階認証も、中小企業や個人開発では「面倒そう」「作るのが大変そう」という理由で後回しにされがちです。ただ、今回やってみて感じたのは、オーセンティケーター方式の二段階認証は、仕組み自体はそれほど複雑ではないということです。登録画面、コード入力画面、そしてアプリごとのON・OFFの設定。この3つがそろえば、実用になります。

まずは、いちばん守りたい管理画面だけでもONにしてみる。そこから、必要に応じて他のアプリに広げていく。それくらいの気軽さで始めるのが、続けるコツだと思います。

【この記事が興味深かった方は、以下記事もおすすめです】

＜おすすめ記事①＞ 一度のログインで、複数のアプリに入れる認証基盤を、AWSとClaudeで作った話はこちら。

＜おすすめ記事②＞ オーセンティケーターの次の一歩、パスキーをAWSのCognitoで実装した記録はこちら。

＜おすすめ記事③＞ Cognito + Google OAuthで詰まった3つの罠を知りたい方はこちら。