パスワードレスなユーザー認証時代を迎えるために開発者は何をすべきか

# パスワードレスなユーザー認証時代を迎えるために開発者は何をすべきか

## 概要

最近は「パスワード不要」というパワーワードとともに WebAuthn/FIDO が話題に上がり、”ユーザー認証周りに変化が訪れそう”な雰囲気を感じます。
Google や Yahoo! JAPAN のように、自社で幅広いサービスを展開するだけではなく他社や一般開発者のサービスにID連携の仕組みを通してアカウント情報を提供しているようなところは新しいユーザー認証方法のための仕様策定に積極的に参画したり、自身の提供するサービスで採用を始めています。
一方で、そこまでDigital Identity分野にリソースをつぎ込めないサービスの開発者はこのような変化に対してどのように対応していけば良いのでしょうか。

本投稿の内容は、

* 新しくアカウントシステムを設計/実装する
* 既存のアカウントシステムで新しい認証方式をサポートする

という場面で、何を考えるべきかを整理してみたものです。

## 現状よく使われているユーザー認証方法

現状、”よく使われている”ユーザー認証方法はこの辺りでしょう。

* メアド(もしくは電話番号、サービス内のユーザーID) + パスワード
* ソーシャルログインと呼ばれる、外部の Identity Provider とのID連携を利用

それに加えて、2段階認証やバックアップ用途で利用されている方法として、以下のようなものが使われています。

* ワンタイムパスワード(OATH準拠)
* バックアップコード(無くしてはいけない数字列10個ぐらい)
* FIDO U2F対応デバイス

これらの組み合わせでユーザー認証機能が実装されているのが一般的と言えるでしょう。
また、アカウントリカバリーの方法として

* アカウントと紐づけられているメールアドレス、電話番号へURLなり認証コードなりを送る(+αとして登録されている属性情報を入力させるなど)

なども利用されています。
実際にメールやSMSに認証コードを送る方法をログイン時に提供しているサービスもありますし、最終的にユーザーがログイン状態になるという点からはこれもユーザー認証方法として扱っても良いと思います。

## パスワードレス時代への過渡期となるために必要な流れ

上記のように、現在でもパスワード認証以外の認証方法は用意されています。
業界全体で次のような流れを作る必要があるでしょう。

* WebAuthn / FIDO 対応ブラウザ/デバイスの普及
  * 以前の FIDO で UAF と呼ばれていた、対応デバイス所持 + 生体認証の組み合わせ
* パスワード登録が不要なアカウント登録の普及
  * 登録フローからパスワード設定を取り除く
* (既存サービスの)パスワード認証の無効化の普及
  * 別の認証方式をサポートし、ユーザー移行の促進

新規サービス / 既存サービスの何れにしても、開発者にとって重要なのは、2の対応を進め、サービス利用開始時点からパスワード認証を利用しない**「パスワードレスネイティブ(とかパスワードレス世代とか呼びたい人達)」**を生み出すことだと思います。
PC向けのサービスがスマートフォンへの対応を迫られたいわゆる「スマホシフト」の後に現れた「スマホネイティブ」のように、「パスワードレスネイティブ」を生み出すための「パスワードレスシフト」を広い範囲で進める必要があります。

**なんか言いにくいので「パスワードレスネイティブ」「パスワードレスシフト」は流行らないと思う。**

## パスワードレスネイティブのための登録フローの課題

パスワード認証を利用しないということは、アカウントに紐づくセキュリティデバイスを所持したり、メールやSMSにアクセスできるかどうかを認証に利用します。
当然、今まで「なんとなく簡単なパスワードを設定していたユーザー」に比べると、

* 登録/ログイン処理の複雑化
  * フォームにパスワードを設定する必要がない代わりに、対応デバイスの登録処理が必要になるなど
  * FIDO対応デバイスを持っていないユーザー、特殊な UX を必要とする環境のサポート
* デバイス紛失時などのリカバリー機会の増加

などの課題が出てくるかもしれません。

* UX最適化によりシンプルな登録フローを提供して離脱を阻止
* 複数の認証方法をサポートし設定可能にすることでリカバリーコストの軽減

という2つの要件を共に実現することは、ユーザーにとっては相反するアクションとも言えます。
安全な登録 / ログイン処理を行うためのベストプラクティスの検討、啓蒙についても今後ますます必要になりそうです。

## 既存サービスの対応コスト

既存のサービスのユーザー認証をパスワードレスにしようと思うと、それなりの改修コストが発生するでしょう。

* 認証方式の多重化
* “新鮮な”連絡先の保持(主にリカバリー用途)
* パスワード認証の強制無効化

パスワード認証に代わる認証方式への移行について、最初はユーザーに任意でやってもらうことになると思いますが、軽く想像するだけでもだいぶ辛そうです。
メールアドレスや電話番号など、一度確認済みとなっている連絡先情報が最新のものであれば、認証コードを送って認証する方式への移行を進めるという手もあるかもしれません。
Twitter や Google のように、連絡先が最新のものかどうかを確認する手段を用意しておくことも必要になるでしょう。

完全移行のためには、強制的にパスワード認証を無効化するという手段もありますが、相当慎重にやらなければ離脱するユーザーが出てきそうです。
FIDO対応デバイスのブランディングと共にサービス側も移行キャンペーンを打つような流れになるんでしょうかね。

## ID連携のあり方

大手サービスがパスワードレスな方向に進めている場合、そのサービスとのID連携を用いることが一番コストを抑えつつパスワードレスなユーザーをサービスに迎え入れられるとも言えそうです。
ID連携を利用する場合で、認証方式そのものは Identity Provider 側が持つことにはなりますが、

* サービス側で1つのアカウントに複数の Identity Provider のアカウントを紐づけられるようにしておく
* サービス側が Identity Provider により確認済みの連絡先を保持し、リカバリーに利用
* サービス側で必要な認証強度を Identity Provider 側に指定、もしくはユーザーの認証強度を Identity Provider 側から取得できるようにする

といった実装をしっかりやることで、今までよりもセンシティブな処理を実装することが可能になりそうです。

## まとめ

以上、現時点で思っていることを書き連ねてみました。

* 待っていてもそう簡単にパスワードレス時代はこない
* “パスワードレスネイティブ”を増やすための仕組みが重要
* ID連携を"ちゃんとする"ことで低コストで対応可能かも

おまけ : 具体的なベストプラクティスのような、Digital Identity 分野の議論する場として idcon と言うのがあります。興味がありましたらどうぞ。
[#idcon vol.24 ~ #fidcon 再び](https://idcon.connpass.com/event/84839/)

**宣伝** : builderscon 1028 tokyo の Call For Proposals にて本テーマについて応募し、採択されました！会場でお会いしましょう！
[パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと - builderscon tokyo 2018](https://builderscon.io/tokyo/2018/session/9f0ac19c-0367-4307-a3d4-e5431d80267e)

ではまた。