ritouです。
"Digital Identity技術勉強会 #iddance Advent Calendar 2022" 13日目の記事です。
現状、Digital Identityを専門とするような開発者がいないような場合に新規サービスを立ち上げようと思ったら、Auth0やFirebase AuthenticationのようないわゆるIDaaSを利用するのも選択肢として上がるでしょう。
いわゆるID基盤的なものを0から設計、実装できるような 俺の考える最強の...みたいなの を既に見つけてる感じの人からすると「ちょっと違う」「凝ったことやろうとすると機能というか自由度が足りない」「帯に短し襷に長し」みたいな意見が出ることもありますが、現状だけではなくDigital Identity分野の今後のトレンドを追いつつ機能追加していくみたいな長い目で見た時にはそれなりに有用なものであると思います。
今回は そんなIDaaSをおすすめするに至る考え方みたいなところ を紹介します。 内容はほとんどが 個人的な考え なので、解説記事のようなものが多い Zenn ではなくここに書いています。
1. 認証機能の自前実装よりもソーシャルログイン/ID連携
まずはここからです。いつも言ってるやつですね。
そういえば今年、10月に DroidKaigi 2022 というカンファレンスでお話をしてきました。
前半はユーザー認証の現状に至るまでの経緯的な部分を自分の目線でまとめたもの、後半は手元のスマートフォンを用いてログインする仕組みについて紹介しました。
パスワード認証 -> リスト攻撃に対するTOTP -> スマホアプリを使ったPush通知を用いた認証 -> それらでも防げないフィッシングに対抗できるFIDO認証からパスキーへみたいな複雑な流れを側で見てきた身からすると、現世において1からユーザー認証機能を実装して運用することは大変に難しくなっていると言えるでしょう。
これまでWebアプリケーションの認証機能を実装する方法としてよくこんな分類をしていました。
1で多要素認証やリスクベースなしくみを考えるには私みたいな専門家ぶったエンジニアを雇う必要があります。 となると2のように既にあるものを組み合わせていくかとなるところですが、パスワード認証 or ソーシャルログインぐらいしかなかった時代に比べて、実現したい認証機能のどこまで実現できるのか、自分が想像する挙動になるかどうか良く調査、検証した上で実装していく必要があるでしょう。となると、3でしっくりくるサービスがあったらそれを使うのも一つの手ですね。
また、2や3でも、最近は普通にソーシャルログインやID連携とよばれる機能を "普通に、そこそこ安全に" 実現できる仕組みが増えてきました。深く考え始めるとキリがないユーザー認証方式の設計について考えるのはもう大手のところに任せ、ソーシャルログイン/ID連携と呼ばれる方法でそれらのユーザー情報を利用する方が開発/運用コストともに良さそうです。これは今後パスキーのようなどんな安全な認証方式が普及したとしても変わらないどころか、より安全なIdPやユーザーが使いたいIdPを選んでID連携するような世界に近づくのかなと思っています。
2. 認証以外にもあれこれ必要なID管理機能
ソーシャルログインでユーザー認証機能が実装できたところで、そもそもそれだけ実装したらいいわけでも無いのが実情です。 新規登録から退会まで、いやその先もまだあるかも知れませんが、いわゆるID管理といった機能が必要となります。 昔は良い意味での疎結合的な割り切りで各種トークン取得のところまでしかしないライブラリがあってそこと自前のID管理の仕組みをつなぐ必要があったりしました。今はそれなりに改善されてつなぎも楽にできるものがありそうですが、ここで変な実装をしてしまうと後で困ることになります。
この辺りは以前、記事を書きました。
ID管理における状態遷移と言ったらイメージしやすいかも知れませんが、ある程度ちゃんとしたサービスを作ろうと思うとこのIdentity Lifecycle というものを意識する必要があります。 とはいえ、この辺りはサービスに必須である機能ではあるものの、サービスが提供したい本質とは異なります。これにどれだけコストをかけられるのかを考えると、自前でやるよりもこの辺りをまとめて面倒見てくれる外部のサービスを利用した方がいいってなりますよね。
そこでIDaaSでしょうとなるわけです。 むかーしからあるmBaaSみたいにアプリのバックエンドに必要な機能を全部SaaSに任せろとは言いません。ざっくりID周りだけ頼む、他は自分たちで頑張るからってのができるのが最近のIDaaSの良い面であると思います。
3. 独自認証の選択肢、将来的な機能追加まで考える
さっきはソーシャルログインだけでいいって言いましたが、他にもありました。ごめんなさい。
ID連携って言うと、どうしても "IdPに何かあったら" "結局自前でも認証機能が必要なんじゃないの？" みたいな話が出てきます。 IdPやってるようなところが急になくなるとは考えられません(Twitterみたいに不安になることはあるかも？)が、そこのログインが一時的に止まったり、アカウント単位でBANされたりは想定しておく必要はあるでしょう。 サービスの内容によっては、その時にアカウントリカバリー用途として別の認証機能と設定変更の機能が必要になるでしょう。最近だと、TwitterでZennのGoogleアカウントの切換機能を目にしました。まさにこれの話です。
ID連携のみを利用するリスクとしてIdPが一時的に使えない状態だったり、アカウントが停止された時などがある。Zennは後者の状態からの復帰手段として専用のメールアドレスを設定することで別のアカウントに付け替えられる手段を提供しているのか。 https://t.co/wAPXObjmm8
— 👹秋田の猫🐱 (@ritou) 2022年12月6日
Zenn の場合は専用のメールアドレスを利用した認証を行った上でGoogleアカウントの切換と言う設定変更の機能が提供されるわけです。
IDaaSにはID連携だけではなく他の認証方式も最初から利用できるものや、その選択肢にない場合に拡張可能なところもあります。また、今はなくてもこれから勝手に対応してくれるものもあるでしょう。
最近だとパスキー/Paskey/passkeyと呼ばれる仕組みが話題ですが、IDaaSの中にも早い段階で実装してくるところ、時間がかかるところがあると思います(例えばAuth0は早そう)。
現在のFIDO2(WebAuthn)と呼ばれるあたりの扱いにおいても既に実装されていたり、カスタム実装で実現可能なところなどがあると思います。IDaaSの機能を利用して安全な認証方式が利用できるのであればアカウントリカバリーもしくは利便性向上あたりでID連携と併用して実装するのもありだと思います。 初期の機能開発におけるコストだけではなく、運用コスト、将来的な機能追加まで見据えてIDaaSの採用も検討してみるのも良いと思います。
PR ちょうど良い本、あるよ
そういえば "Firebase Authenticationで学ぶ ソーシャルログイン入門 ID管理の原則にそった実装のベストプラクティス" とかいう本が 昨日2022/12/12に発売された らしいです。
@authyasan が今回の記事のような話を実際に手を動かしながら実感/理解できるように書かれた本です。
自分も監修としてたくさん意見をお伝えして参考にしてもらったので、あれこれどっかで見たことある考えや言い回しだと思ってもらえるかと思います。良かったら読んでみてください。
明日のアドカレ
ついに @phr_eidentity さんの登場ですね。 DID/VCあたりの最新のお話が聞けそうです。
ではまた！
