アプリやウェブサービスを作る際、『認証機能』が必要になるケースは少なくありません。
認証機能はサービスのセキュリティを守る上で非常に重要な箇所ですが、１から作る人は殆どいらっしゃらないでしょう。非常に複雑な上、正確さが求められる箇所だからです。
基本的には、Auth0やFirebase Authentication等の『クラウドの認証基盤（IDaaS）』と呼ばれるサービスを利用するか、フレームワークに付随した認証機能を使うことがほとんどでしょう。
では、そのどちらがより”適した”認証方法なのでしょうか？
結論：外部向けサービスなら認証基盤、社内向けの小さなシステムならフレームワーク
先に結論を述べます。
もしあなたの作っているアプリが『外部向けのサービス』として世に出すのであれば、認証基盤を使いましょう。
認証基盤は費用がかかる代わりに、とても強力なセキュリティを備えた認証機能を使うことが出来ます。新たな攻撃手法が見つかった場合も、セキュリティの専門家がいち早く対応を行ってくれるため、非常に安心です。
更にSNS認証や二段階認証等の、ユーザーが必要とするサービスについても、手っ取り早く実装することが出来ます。
一方で、社内向けのサービスや、ごく少人数しか利用しない小さなシステムであれば、そのままフレームワークの認証機能を用いたほうがいいでしょう。
フレームワークを用いた開発であれば、そのまま付随した認証機能を使うことで、ほぼ手間を掛けずにログイン機能を作れます。
また、認証基盤に必要な月々のコスト等もかかりません。
ただしセキュリティについては、認証基盤に比ると劣ります。
また、セキュリティのアップデートが行われた際も、自身でそれらをアップデートしなければなりません。
このとおり『外部向けのサービス』ならば『認証基盤』、
『社内向けのサービス』ならば『フレームワークの認証機能』を用いるのが適切なのです。
認証基盤(IDaaS)のメリット
ここからは、それぞれのメリット・デメリットについて見ていきましょう。
セキュリティ強度が高い、２段階認証などを使える
認証基盤のセキュリティを管理しているのは、世界でも有数のセキュリティ専門家ですし、SMSや認証アプリを用いた二段階認証を簡単に導入できます。なので非常に安心してセキュリティを任せることが出来ます。
更に認証基盤によっては『パスワードが漏れた際、いち早くそれを検知しリセット作業を行う』といった機能も有しています。これにより、パスワードが漏洩しても、情報漏えいのリスクを防いでいるのです。
これは認証基盤にしかできない対応です。
追加機能を素早く開発
もしフレームワークの認証機能を用いている状態から、『各種SNSでの認証もできるようにしよう』と考えた場合、どのぐらいの工数が掛かるでしょうか。
Google・Facebook・twitterに絞ったとしても、それぞれの認証用のAPIを取得し、仕様を把握、UIを作り、それぞれの規格にあった形で実装を行う……となれば、相当な工数を割かなくてはなりません。
しかし認証基盤を使うのであれば、APIキーの取得も管理画面から行えることがほとんどですし、設定時間もほとんど要りません。
場合によってはUI自体用意されているため、ものの数分で実装が完了してしまいます。
これらは『２段階認証』や『パスワードレス』機能等を使いたいときにも、同様のメリットがあります。
認証機能の保守コストを下げられる
フレームワークに付随している認証機能というのは、最低限の攻撃には耐えられるよう実装が行われていますが、脆弱性が見つかることも珍しくはありません。
万一そこを突かれたときの責任はフレームワークの制作者ではなく、アプリの開発者にあります。
更に、フレームワーク側がそれに対応してアップデートを発表したとしても、そのアップデートを反映させるのは開発者の責任です。
ただアップデートするだけならばそこまで時間はかからないかもしれませんが、
アップデートを実装して問題が生じないか、問題が生じたときのロールバックや対応等についても、全て開発者が責任を追わなければなりません。
しかし認証基盤を用いるのであれば、それらの保守コストは一切必要ありません。
最新の攻撃にも耐えられるよう、認証基盤には日々アップデートが施されており、ほとんどは自動で反映されます。
また漏洩時の自動保護等、フレームワークの認証機能では付けられないような、高度な保護機能も備わっています。
こういった保守コストの差についても考慮した上で、どちらを利用するのか決めてください。
認証基盤のデメリット
費用が高い
『強力なセキュリティを保持できるなら、認証基盤を使ったほうが明らかに賢いのではないか』と思うかもしれませんが、そこには費用の壁が立ちはだかります。
認証基盤にはいくつかのプランが用意されており、その多くは月間アクティブユーザーによって切り替えが行われます。
例えば月間１万人のアクティブユーザーがいるウェブサービスを持っていた場合、Auth0のエッセンシャルプランでも228ドル(約3万3千円）の費用がかかります。もしプロフェッショナルプランならば1,500ドル（約22万円）です。
……実際にウェブサービスを成功させたことのある方ならばわかると思いますが、月間１万ユーザーというのはそこまで多い数字ではありません。少し話題になればすぐに到達出来てしまう数字です。
その時に認証基盤の費用を賄った上でマネタイズできるのかどうか、その判断は慎重に行う必要があるでしょう。
導入するときに専門知識がいる
一見、認証基盤を使ったほうが楽に実装ができるのではないか、と思うかもしれませんが、一概にそうとは言えません。
確かにAPIやSDKを用いれば、認証基盤は簡単に導入できるように見えるかもしれません。
しかしログイン時の挙動や各内部権限との紐づけ等は、フレームワークの認証機能を用いるより、かなり複雑になってしまいます。
『認証部分は認証基盤を使うから、最後にちょこっと時間を使えば実装できる』と考えてしまっているのであれば、泣きを見るかもしれません。
フレームワークの認証機能を使うメリット
今度はフレームワークの認証機能を使う場合について見てみましょう。
デフォルト機能ならば簡単に実装できる。
もしあなたの使うフレームワークに認証機能がついているのであれば、ほとんど苦労することなくそれを使うことが出来ます。
ログインする箇所はもちろん、会員向けの表示や、各内部権限との紐づけについても、ドキュメントに沿った形で簡単に実装が行えるでしょう。
こういった場合、認証基盤を用いるよりも手早く実装が行なえます。
金銭的なコストが低い。
毎月費用が掛かる認証基盤に比べて、フレームワークの認証機能は基本的に費用がかかりません。
社内のイントラネットからしかアクセスできないようなアプリに、有料の認証機能をつける必要性はほとんどないため、そういったケースでは十分な機能を有していると言えます。
また、先程も述べた通り実装も簡単なので、その分の人的コストを割く必要もありません。
フレームワークとの親和性が高い。
フレームワークに付随する認証機能を使う場合、実装やログイン周りの設定で混乱することはほとんどないでしょう。ログイン画面やログイン済みのユーザー向けの表示等、ドキュメントを見ればそのまま実装が可能です。
しかし、認証基盤はあくまで外部のサービスなので、実装にはそれなりの手間がかかります。
また『正しく接続されているか』のテストも怠るわけにはいきません。
作業時間・実装の難易度で見れば、フレームワークに軍配が上がります。
フレームワークの認証機能を使うデメリット
セキュリティ強度を高くするのが大変
『認証基盤でのメリット』でも語った通り、フレームワークの認証機能を使う上で、一番の弱点はセキュリティ強度です。
例えば一定回数パスワードを間違えた場合、Auth0であれば『Brute-force Protection』が働き、同一IPからのリクエストがブロックされます。
これにより『ブルートフォース攻撃』を無効化している訳です。
それと同時にAuth0はログイン試行したIDの持ち主へメールを送り、ログイン試行されたことと、ロックの解除方法についての案内を送る機能もついています。
本物の攻撃であれば、パスワードを変更する等の防御策を取ることが出来ますし、
もし単にIDの持ち主がパスワードを忘れただけであれば、ロックを解除して再度ログインの試行を行えます。
こういった策は、もしフレームワークの認証機能を使っている場合、自前で設定を行わなければなりません。
単純にIPからの連続ログインを禁止するだけであれば、簡単に設定出来るかもしれませんが、ユーザーに警告を発したり、ロックを解除する仕組みを作ったり……となればかなりの労力を要するでしょう。
２段階認証・SNS認証などの開発コストが高い
先程の項目とも重なる部分ですが、二段階認証やSNS認証を取り入れるのも、自分で行うのは大変です。
例えばSMS認証を行う場合、よほど腕に覚えがある方以外は、ワンタイムパスワード専用のAPIを利用した実装を行うことでしょう。
しかしそもそもAPIにプッシュする仕組みを作るのが大変ですし、SMSが届かなかった場合の仕組みを作る必要があったり等、一筋縄では行きません。
そしてどのみちAPIにコストを支払うのであれば、最初から認証基盤を使うのと、あまりコストが変わらないという事態もありえます。
SNS認証（OAuth認証）についても同じです。
各SNSのAPIキーを取得し、それぞれ違う仕様の認証システムを実装しなければなりません。
１つ実装するだけならば、そこまで苦にならないかもしれませんが、多くのユーザーを取り込むために複数のSNS認証を実装する場合、結構な作業コストが必要となります。
これらは認証基盤を用いれば、いずれも簡単に実装できる機能です。
もしこれらの実装に長々と時間を掛けるぐらいであれば、認証基盤を用いて早くリリースしたほうが得かもしれません。
権限分けをする時に開発コストが上がる
認証システムというのは、『ログインさせるかどうか』だけを問う場所ではありません。
特に社内システム等では、『特定のグループにしか見せては行けない情報』『その中でも特定のユーザーにしか編集が許可されていない情報』『それらの権限を付与・剥奪する権利をもったユーザー』といった具合に、グループ・ユーザーごとで権限が異なります。
こういった権限付与については、実は認証基盤のほうが得意なのです。
もちろん、簡易的に権限管理が実装されているフレームワークもあります。
それで用が足りるのであれば全く問題ないのですが、
複雑な権限設定を行おうとすれば、その枠組から外れないといけないことになり、返ってデフォルトの権限管理が邪魔になることもあるでしょう。
一方で多くの認証基盤の場合、開発者向けに権限管理が行いやすいようシステムが整備されています。
ユーザー単位だけでなく役割単位で設定も行えるため、社員が増えるごとにいちいち権限付与を行う必要もありません。グループの中に放り込むだけで設定が完了します。
もし初めて複雑な権限設定を実装する場合は、認証基盤を使うのがおすすめです。
必要な制御やUI等をそこで知ることができるでしょう。ひょっとしたら最初の想像以上に、複雑で手間がかかることに気づくかもしれません。
認証部分の開発・認証基盤の実装はお任せください
ここまで認証基盤や、フレームワークの認証機能について解説してきましたが、
もし初めて認証部分を実装する場合、不安を感じるかと思います。
認証部分はサービスの質を左右する箇所ではありませんが、誤った実装を行った場合、致命的なインシデントを引き起こす場所となります。
例え認証基盤を使ったとしても、JWTトークンやAPIキーを漏らしたり、誤った権限設定を行ってしまうだけで、悪意のあるコードを埋め込まれたり、顧客情報が流出するという事態になりかねません。
なのでもし実装を任せたい場合や、経験者の知見が欲しい場合は、ぜひお問い合わせいただければと思います。
認証部分の開発から、認証基盤の導入まで、細かくアドバイスを行うことが可能です。
必要であればいつでもお問い合わせください。
お問合せ＆各種リンク
- お問合せ：GoogleForm
- ホームページ：https://libproc.com
- 運営会社：TodoONada株式会社
- Twitter：https://twitter.com/Todoonada_corp
- Instagram：https://www.instagram.com/todoonada_corp/
- Youtube：https://www.youtube.com/@todoonada_corp/
- Tiktok：https://www.tiktok.com/@todoonada_corp
presented by
