③【SSO認証キット】オーセンティケーターの次はパスキー｜FIDO・WebAuthnとの関係を整理して、AWSのCognitoで実装した記録

「FIDO」「FIDO2」「WebAuthn」「パスキー」。そして、スマホでおなじみの「オーセンティケーター」。

IT資格の勉強で「FIDO」と覚えたのに、AWSのドキュメントを開くと「WebAuthn」と書いてある。スマホの画面には「パスキー」と出てくる。これ、全部別のものですか？

結論から書きます。「FIDO」「FIDO2」「WebAuthn」「パスキー」は、ほぼ全部、同じ仕組みの、呼び名違いです。 「オーセンティケーター」だけは仲間ではなく、一つ前の世代の方式です。 そして、AWSのCognitoを使えば、個人開発でも、パスキーでログインできる認証基盤が作れます。

マンチーは、自作のSSO認証キットに、オーセンティケーター(認証アプリ)に続いて、パスキーを足しました。この記事では、名前の混乱を整理したうえで、実装の流れと、ハマったところを、正直に書きます。

この記事は、SSO認証キットの連載③です。①の完成編と、②のオーセンティケーター編も、あわせてどうぞ。

こんな方に向けて書きました。

• IT資格の勉強で、FIDOやWebAuthnの関係がごちゃごちゃになっている方

• 個人開発で、ログイン機能を作っている方

• スマホのオーセンティケーター(認証アプリ)で、6けたの数字を使っている方。その次の形を知りたい方

(2026年11月時点の情報です。AWSの料金や条件は変わることがあるので、公式ページで確認してください)

まず、名前が多すぎる問題を片づけます

整理すると、こうなります。

• FIDOアライアンス：パスワードに頼らない認証の標準を作っている、業界団体です

• FIDO2：その団体が定めた、規格の名前です

• WebAuthn(ウェブオーセン)：FIDO2のうち、ブラウザやWebサービスから使うための仕様です。Webの標準化団体のW3Cが標準にしています

• CTAP(シータップ)：FIDO2のうち、スマホやセキュリティキーのような機器と、パソコンやブラウザが、やりとりするための仕様です

• パスキー：FIDO2の仕組みを、ふつうの人向けに呼ぶ名前です。2022年に、Apple、Google、マイクロソフトなどが、足並みをそろえて打ち出しました

• オーセンティケーター：スマホのアプリが、6けたの数字を出す方式(TOTP)です。FIDOとは別の仕組みで、パスキーの一つ前の世代にあたります

つまり、こう覚えると、混乱しません。

資格では「FIDO」、AWSでは「WebAuthn」、スマホの画面では「パスキー」。

どれも、同じ仕組みの話です。

パスワード、TOTP、パスキー。何が違うのか

ここが、いちばん大事なところです。3つを並べます。

パスワード

サーバーが、パスワードを(ハッシュという形に変えて)持っています。サーバーから漏れると、解析される恐れがあります。それに、偽サイトに入力してしまえば、そのまま盗まれます。

TOTP(オーセンティケーターの6けたの数字)

スマホのオーセンティケーター(認証アプリ)が出す、30秒ごとに変わる数字です。TOTPは「時間で変わるワンタイムパスワード」の略です。パスワードだけよりは、ずっと安全です。ただ、この方式は、サーバーの側にも「もとになる秘密の値」を置いておく必要があります。そこが漏れれば、同じ数字を作られてしまいます。偽サイトに入れた6けたも、その場で使われる恐れがあります。

パスキー

端末の中で、鍵のペアを作ります。サーバーに預けるのは、公開鍵だけです。

たとえるなら、こうです。サーバーが預かるのは「錠前」だけ。「鍵」は、端末の中から、一歩も出ません。錠前を盗まれても、そこから鍵は作れません。

しかも、この鍵は、登録したサイトのドメインと結びついています。偽サイトでは、端末が鍵を出してくれません。フィッシング(偽サイトで情報を盗む手口)に強いと言われるのは、このためです。

もちろん、万能ではありません。端末をなくしたときの話など、後で正直に書きます。

マンチーの構成は「全部入り」です

マンチーの、SSO認証キットの中身は、こうなりました。

• パスワード認証(Cognito)

• TOTP(オーセンティケーター)

• パスキー

• アプリごとに、二段階認証のON・OFFを切り替えられる設定

個人で作るものとしては、かなり欲張った構成だと思っています。(SSOの話はこちら、二段階認証の話はこちらです)

AWSのCognitoで、パスキーを足す流れ

大まかな流れは、次の4つです。細かい設定項目や画面は、更新されることがあるので、実際の作業は、公式ドキュメントを見ながら進めてください。

1. プランを「Essentials」以上にします。 公式の料金ページでは、パスキーに対応しているのは、EssentialsとPlusです。いちばん下のLiteでは、対応していません

2. サインイン画面を「マネージドログイン」にします。 これも、Essentials以上の機能です

3. 「選択ベースのサインイン」で、パスキーを有効にします。 ユーザーが、使える方法の中から選んでログインする仕組みです

4. パスキーを登録する入口を作ります。 マンチーは、管理画面の上に「パスキー登録」のボタンを置きました

ここまで書いて、正直に言うと、意外なほど簡単でした。 これは、AWSのおかげです。

パスキーの、いちばん難しい部分である、鍵の検証を、Cognitoが引き受けてくれます。自分で暗号の処理を書く必要は、ありませんでした。やったのは、プランを選んで、設定を有効にして、登録の入口を置くことです。

一方で、TOTPは、自分で実装しました。こちらは、秘密の値の保管など、考えることが多くて、苦労しました。二つを比べると、マネージドサービスに任せられる部分は、任せるほうが、安全で、しかも楽だと、あらためて感じました。

「プランを上げる」と聞くと、費用が心配になると思います。でも、意外な事実がありました。

費用：個人開発の規模なら、追加費用は出にくい

公式の料金ページによると、直接サインインのユーザーには、月に1万人まで無料の枠があります。この無料枠は、LiteとEssentialsに適用されます(Plusには適用されません)。

個人開発やポートフォリオの規模なら、パスキーのための追加費用は、かからないことが多いと思います。ただし、次の点には、注意してください。

• 無料枠の条件は、変わることがあります。作る前に、公式ページで確認してください

• メールやSMSの送信は、別料金です

• 利用者が増えて、無料枠を超えたら、費用がかかります

「個人でも、本格的な認証基盤を作れる」。この時代の変化は、ありがたいと感じました。

オーセンティケーター(TOTP)とパスキーを、共存させる

ここは、設計で悩んだところです。

マンチーのキットには、すでにTOTPがありました。そこへパスキーを足したので、「どちらでログインしたか」で、扱いを分けることにしました。

• パスワードでログインした人には、TOTPを求める

• パスキーでログインした人には、TOTPを省略する

パスキーは、一般に、「端末を持っていること」と「指紋や顔、PINで本人が操作したこと」の両方を、1回で確かめる仕組みです。ですから、さらにTOTPを求めなくても、安全性は保てる、と考えました。

どちらでログインしたかは、ログインのあとに受け取る証明書(トークン)の中の情報で、判定しています。

アプリごとに、二段階認証のON・OFFを切り替えられる設定も、そのまま活かせています。

ハマったところ(失敗談です)

きれいに進んだわけではありません。ハマったところを、2つ書きます。

ハマり①：Lambdaの関数URLが、403で使えなかった

二段階認証の処理を、新しいLambdaの関数URLで公開しようとしたところ、403のエラーが出て、使えませんでした。

結局、新しいURLはあきらめて、すでに動いているLambdaに、二段階認証の処理を相乗りさせることで、解決しました。きれいな設計ではないかもしれません。でも、動くことは、大事です。

ハマり②：TOTPの「秘密」を、データベースに置く問題

TOTPを自分で実装すると、利用者ごとの「秘密の値」を、データベースに保存することになります。これは、先ほど書いたとおり、パスキーより、セキュリティの面では劣る部分です。

実装してみて、あらためて感じました。パスキーに移れれば、この「保管する秘密」が、そもそも要らなくなります。 サーバーが持つのは、公開鍵だけだからです。

正直に書く、限界と宿題

いいことばかりでは、フェアではないので、書いておきます。

• 端末をなくしたとき、どう入り直すか。 鍵が端末の中にあるからこその、悩みです。複数の端末に登録しておく、別の手段を用意しておく、といった設計が必要になります。ここは、どんな認証基盤でも、きちんと考える部分です

• パスキーに対応していない、古い環境が残っています。 そのため、パスワードやTOTPも、しばらくは残しておく必要があります

• この記事は、個人のシステムでの一例です。 他の人のデータを預かる本番の仕組みに使う場合は、専門家にも相談してください

万能ではありません。でも、「パスワードだけ」の状態と比べれば、大きく前進します。

まとめ：名前は違っても、同じ仕組み

• FIDO、FIDO2、WebAuthn、パスキーは、ほぼ同じ仕組みの、呼び名違いです。資格では「FIDO」、AWSでは「WebAuthn」、スマホでは「パスキー」と覚えます

• パスキーは、サーバーに公開鍵だけを預けます。漏れても悪用されにくく、偽サイトにも強い仕組みです

• 実装は、意外なほど簡単でした。難しい検証の部分を、AWSが引き受けてくれるからです。自作したTOTPとは、対照的でした

• AWSのCognitoでは、Essentials以上のプランで、パスキーが使えます。無料枠は月1万人までです(2026年11月時点。条件は公式で確認してください)

• オーセンティケーター(TOTP)と共存させるなら、「どちらでログインしたか」で扱いを分けられます

• 端末をなくしたときの入り直しは、設計が必要な宿題です

IT資格の勉強で見かけた「FIDO」が、自分の作るシステムの中で動く。この体験は、なかなかおもしろかったです(笑)。

読んでくださって、ありがとうございました。

(この記事は、公開されている情報と、マンチーの個人システムでの経験にもとづいています。詳しい情報は、AWSなどの公式ドキュメントをご確認ください)

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

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

＜おすすめ記事②＞
アプリごとにON・OFFできる二段階認証を、オーセンティケーター(認証アプリ)で作った話はこちら。

＜おすすめ記事③＞
ふさいだはずの穴は、なぜ直しても戻るのか。AIは攻撃の道具か、守りの味方かを考えたい方はこちら。

#パスキー #FIDO2 #WebAuthn #AWS #Cognito #オーセンティケーター #認証基盤 #個人開発 #セキュリティ #バイブコーディング #munchie