はじめに

私自身、複数サービスでユーザー認証画面をカスタムUIにて構築を行ったり、それらを最終的に認可サーバへ集約した経験があり、もっと事前に検討すべき内容があったのではないかという後悔から、この記事の執筆に繋がっています。

サービスを早期投入したいという要求に対して、カスタムUIで簡単に認証画面を構築できるツール・ドキュメント群が揃っている現状で、少しでも選択肢の幅が広がれば幸いです。

カスタムUIの利点

サービスに最適なデザイン（CSS）やユーザー認証導線を作ることが可能です。

エンドユーザーにとってもシームレスな体験となり、CVRに直結するかもしれません。

ですが、サービスを使いたいユーザーの行動を止めるほどのユーザー認証があるでしょうか？

ITサービスが常識の現代において、ユーザー認証は特別なものでなく、サービス利用の入り口であるという認識も広く行き渡っているはずです。

ユーザー認証はサービスにとって必須機能ではありますが、他社との競争優位性を作り出すまでのビジネス重要性はありません。

こういった点を十分に考慮して、ユーザー認証画面をカスタムUIで持つという選択で良いのかを考えられると良さそうです。

Rest APIとOIDCプロトコル

実装難易度において、カスタムUIは取っつきやすく、Rest APIコールを行う便利なSDKが提供されており、直感的に構築可能です。

ただ、ここは中長期の目線を持って判断してほしいです。

カスタムUIを持つということは、自社が提供するサービス群が増えると、同じような実装でユーザー認証を持つということになります。１、２サービスであれば許容範囲かもしれませんが、必ず、100%、確実にメンテナンスコストで問題が発生します。そして、中長期的に技術負債として取り扱われます。

認可サーバーを認証基盤として独立させる形式の場合、OIDCプロトコルへの一定理解が必要であったり、IDaaS提供の認可サーバーを流用する場合、UIデザインの自由度が低いことがネックとなり敬遠されがちですが、メンテナンスコストは圧倒的に低くなります。サービス群が増えていっても、プロトコルに従いクライアント（RP）を追加していくだけなので、最終的にはサービス投入を早くしたいというビジネス要求にも応えられることになります。

サービス群は増えていく

完全に経験則ですが、自社が提供するサービス群は必ず増えます。

カスタムUIで構築している場合、新サービス増加を構築するごとにユーザー認証のような共通機能を追加していくことに危機感を覚え、共通ライブラリ化する or 認可サーバー移行するという状況にたどり着きます。

ここで難しいのが、カスタムUIといえど、各サービス群に共通機能的に構築されていたはずのユーザー認証が、サービスごとに微妙にカスタマイズされ容易に引きはがすことができなかったり、OIDCプロトコルの知見不足により選択肢が共通ライブラリ化一択になってしまうという点です。

散らばっているものを集約するのは骨が折れる作業です。特に走っているサービスへの対応となるケースがほとんどだと思うので、導入時よりも神経質にならなければいけません。

ユーザー認証機能とは

ユーザー認証機能は競争優位性に繋がらないが、サービスにおいては必須機能です。途中で、ユーザー認証を無くそうという話にも絶対にならないです。

つまり、あなたの会社・サービスが存続し続ける、ユーザー認証機能もメンテし続けていく必要があります。

長く付き合うのですから、中長期の利点により重きをおくべきと私は考えています。

最後に

ユーザー認証に関わるケースは多くないかもしれませんが、この記事を読んだ方のお役に立てれば幸いです。