話題の「パスキー」は「シングルサインオン」と何が違うのか？

パスワードだけの認証では安全とは言えない。そのため、多要素認証やパスキーなどの改善策が生まれた。シングルサインオンもその一つだ。パスキーとシングルサインオンは何が違うのだろうか。それぞれの利点と欠点は何だろうか。

[畑陽一郎，キーマンズネット]

　パスワードは覚えにくく、サイバー攻撃を受けると漏えいしやすい。認証手段としては不完全だと言えるだろう。このような欠点を改善するために多要素認証やパスキー、シングルサインオン（SSO）といった技術が利用され始めた。

パスキーとSSO、何が違うのか

　パスキーもSSOも、パスワードの欠点を改善するという点では似ている。ではどこが違うのだろうか。利点と欠点は何だろうか。

　1Passwordのステイシー・ハリス氏（コンテンツクリエーター、ストラテジスト）は、パスキーとSSOについて次のように簡潔にまとめた。

　「パスキーはパスワードでは決して実現できなかった、よりシンプルで安全な認証体験へと人々をシフトさせる有力候補だ。パスキーで保護されたアカウントにアクセスするために必要なのは、生体情報かデバイスのパスコードだけだ。パスキーは素早く簡単に使え、他の認証方法よりも安全だ」

　ではSSOはパスキーとどこが違うのだろうか。

　「SSOのユーザーはアカウントごとにID／パスワードといったクレデンシャルを個別に使用するのではなく、（「Amazon Web Services」（AWS）や「Microsoft Azure」などの）単一のIDプロバイダーを使用してアカウントにサインインできる。ユーザーはアカウントごとに固有の認証情報を覚える必要がない。SSOプロバイダーにログインするだけでよい」（ハリス氏）

パスキーとSSOはどちらが優れているのか

　パスキーとSSOはパスワードを代替するという意味では似ているが、細部が異なる。まずはどのようなユーザーメリットがあるのかを比較してみよう。

短時間で認証が終わるか

　認証の目的はユーザーのアカウントとデータを安全に保つために、ユーザーの身元を確認することだ。だが、ユーザーにとって認証は単なる面倒な作業に過ぎない。これはWebサービスごとに複雑なパスワードを入力しなければならないことを考えるとよく分かる。つまり、ユーザーや企業にとって優れた認証かどうかを判断する第一条件は手間が掛からないかどうかだ。

　SSOを導入すると、SSOプロバイダーにログインするだけでSSOに対応した多数のWebサービスにアクセスできる。すぐに仕事を始めることができ、違うサービスにアクセスしたときに仕事が中断しにくいというわけだ。

　パスキーもパスワードより速い。だが、パスキーとSSOのどちらが速いのかは場合による。パスキーで保護したアカウントにサインインする場合、プロセスは簡単でシームレスだ。ユーザーは指紋や顔をスキャンするか、デバイスのパスコードを入力するだけでよい。実際の認証プロセスはユーザーから見えないところで素早く実行される。だが、利用するサービスが多岐にわたるとサインイン作業が面倒になるかもしれない。

認証のセキュリティは強力か

　認証がすぐに終わるのを目にすると、アカウントの安全性がどうなっているのかが心配になるかもしれない。SSOとパスキーはどちらも安全な認証方法であり、サイバー攻撃のリスクを減らす。だが、SSOとパスキーはやり方が違う。

　SSOを導入すると1人のユーザーに必要なユーザー名とパスワードの数が減る。攻撃対象となるエントリーポイントが少なくなるという利点がある。一方で、欠点もある。SSOのセキュリティの最大のリスクは、単一障害点があることだ。SSOアカウントが漏えいした場合、そのSSOでアクセスできる全てのアカウントが危険にさらされる。SSOを利用する際は、強固でユニークなパスワードを選んで、それを安全な場所に保管しなければならない。

　パスキーはアカウントごとにユニークな値が自動的に作成されるため、あるWebサイトが侵害されたとしても、別のWebサイトの情報は安全だ。漏えいする危険はない。これはパスキーが公開鍵暗号方式を採用していて、パスキーごとに異なる公開鍵と秘密鍵を持っているためだ。

　パスキーでアカウントを保護した場合、WebサイトやWebアプリケーションはユーザーの公開鍵だけを保存する。パスキーを別のWebサイトと同期または共有しない限り、秘密鍵はユーザーのデバイスにのみ保存される。

　攻撃者がユーザーのパスキーを使ってWebサイトなどにログインするには、（ユーザーが意図的に共有していない限り）秘密鍵を盗むためにユーザーのデバイス自体に（物理的に）アクセスする必要がある。遠隔地からの攻撃ではかなり困難だろう。

可用性はどうか

　利便性、安全性の他にも認証では「可用性」が重要だ。一時的なものであっても、認証用の秘密へアクセスできなくなると、仕事が進まなくなるからだ。

　SSOプロバイダーが障害を起こすと、そのプロバイダーに依存している全てのWebサイトにログインできなくなる。プロバイダーの復旧を待つしかない。

　パスキーを使っている場合は、プロバイダーの停止は問題になりにくい。ただし、パスキーの保管方法によっては、問題が起きる。秘密鍵を保管しているデバイスにアクセスできなくなったり、故障した場合は、そのパスキーにのみ頼っていた認証は使えなくなったりするからだ。

実装しやすいのはどちらか

　最後に考えなければならないのは、SSOとパスキーを実装する場合の条件だ。

　ハリス氏によれば、SSOプロバイダーはそれぞれ独自のワークフローを定めていて、ユーザーが所属する組織によっては実装が複雑になり、コストがかかることもある。

　パスキーはSSOよりも実装がたやすい。生体認証やデバイスのパスコードと連動するようにパスキーを設定するだけで、ログインプロセスはバックグラウンドでシームレスに機能するからだ。ただし、パスキーは成長途上にあるため、利用できないWebサイトやアプリケーションが残っている。これが実装上の問題になることがある。

SSOとパスキーのどちらを選ぶべきなのか

　ハリス氏は「どちらか一方を選ぶ必要はない。パスキーはパスワードレスの未来を先導しており、SSOはビジネスと企業のセキュリティに必要な役割を（まだ）持っているからだ」とまとめた。

　SSOを導入すると管理者は高度なアクセス制御を実行できる。どの従業員が職場のメールアドレスで「Google Workspace」のアカウントを作成できるかを、あらかじめ決めることが可能だ。ハリス氏によれば、この機能があるため、パスキーがビジネス環境でSSOに取って代わる可能性は低い。だが、SSOでカバーされない全てのサービスを保護するのに役立つだろう。

　SSOのアカウント自体をパスキーで保護する方法をハリス氏は勧めている。多くのSSOプロバイダーが、ユーザー名とパスワードの組み合わせではなく、パスキーでサインインすることを認めている。企業にとっては従業員のパスワード問題を解決しつつ、SSOの管理権限を企業側で維持できることを意味する。

　SSOとパスキーがうまく連動することで、ビジネス全体のセキュリティ確保に必要な運用コストを抑えることができる。大半のアカウントをSSOで保護し、その他のアカウント（SSOアカウントを含む）は強力なパスキーで保護する。これが結論だ。