アプリのために自分で認証を作成する必要がありますか？

背景#

「私のアプリのために自分で認証を作成すべきですか？」という質問をする開発者が多く見受けられます。答えは単純な"はい"や"いいえ"ではないので、実装を分解して利点と欠点を示す記事を書いて、あなたが決定を下すのを助けたいと思います。

要約 あなたのニーズに合った既存の解決策を見つけることが必要です、全面的なコントロールを望むか、ソフトウェア開発をまだ学んでいるのであればです。

序論#

開発者として、私はこれまでに多くのアプリケーションを構築してきました。使用するプログラミング言語に関係なく、常に構築する必要がある共通の基盤があります：ユーザー認証。

20年前にはすべてが明確で、それは取るに足らない部分でした。

• ユーザー名とパスワードで登録・ログインシステムを実装する。
• ユーザーのセッションを維持する仕組みを作成する。
• セキュリティについては？MD5が答えです。

それで十分でした。その後、「本業」に集中することができました。 MD5について知らない？ソフトウェア開発の「良い時代」を逃しました。現在、開発者はログイン/アップを構築する際にさらなる課題に直面しています。

それは危機的に聞こえるかもしれませんが、私が一つ例を通して詳しく説明します。

例: オンライン書店#

APIサービスとWebフロントエンドアプリを持つオンライン書店を構築しようとしているとしましょう。

まず、"認証"の範囲を定義する必要があります。認証は認証と承認として説明でき、それらは全く異なる定義と使用例を持っています。

これらの概念を詳しく議論するために、CIAM 101: Authentication, Identity, SSOという記事を書きました。

認証方法を選ぶ#

我々の例であるユーザーサインインで"認証"を開始しましょう。ユーザー名とパスワードの方法以外に、ユーザーのコンバージョンやセキュリティを向上させるために採用されているトレンドの方法がいくつかあります。

• パスワードレス、つまり動的検証コード（メールまたはsms経由）
• ソーシャルサインイン（Google、Facebookなど）

方法の選択はビジネス判断に依存しますが、技術努力については次のように考えることができます。

• パスワードレスの場合、メールやSMSで検証コードを送信するベンダーを見つけ、あなたのAPIサービスと統合する必要があります（新しいAPIが必要になるかもしれません）。
• ソーシャルサインインの場合、使用するソーシャルアイデンティティプロバイダの統合ガイドラインに従う必要があります。さらに、書店のユーザーIDとアイデンティティプロバイダの間にマッピングを作成する必要があります。
  • 例えば、ユーザーが [email protected] のGmailアカウントでログインすると、このメールアドレスを書店のユーザー foo にリンクできます。これにより、あなたは統一したアイデンティティシステムを構築でき、ユーザーは将来的に社会的アイデンティティを変更하거うにリンクすることができます。

ログイン体験の設計と実装#

認証方法を決定した後、エンドユーザーにとって円滑でスムーズなログイン体験が次のターゲットです。ここでのコンバージョンは基本的ですが、事業にとっては重要です。なぜなら、それは顧客データを維持する自然な方法だからです。

Airbnbで働いていた時、サインイン体験を多数プラットホームで最適化するために専用のチームがありました。彼らは、どの組み合わせが最高のコンバージョン率を持つかを判断するために、多数のA / Bテストを実施しました。

ビジネスが始まったばかりのときにそうするのは実用的ではありません。しかし、私たちはまだ最善を尽くしてすべての部品を作る必要があります。書店を運営したいプラットフォームは何ですか？モバイルを始めたり、ウェブから始めたり、両方を始めたりすることができます。具体的な設計は、選択した認証方法に依存します。

• ユーザー名とパスワード：最も簡単なもの、ただの数個の入力ボックスとボタンです。
• パスワードレス：電話 / メールを入力して、動的なコードを送信し、検証します。
• ソーシャルサインイン：選択したソーシャルアイデンティティプロバイダからのドキュメントを参照し、視覚的なガイドラインに従い、リダイレクトのロジックを処理し、最終的にソーシャルアイデンティティを書店のアイデンティティとリンクします。

それをより良くするために考慮すべき他のこと：

• 特定の方法のサインインと登録のプロセスを組み合わせる必要がありますか？
• 顧客が自分でパスワードをリセットできる「パスワードを忘れた」フローが必要ですか？

ネイティブ開発を選択すると、追加のプラットフォームに対する作業量はほぼ倍増します。

セキュリティとトークン交換#

セキュリティは見えない氷山となる可能性があります。OpenID ConnectまたはOAuth 2.0に詳しいのであれば、それは素晴らしいです。広く使用され、実戦検証されています。OpenID Connectは比較的新しいですが、「ユーザー認証」に設計されているため、オンライン書店に適しています。

スタンダードの詳細に入ることなく、まだ考慮するべきことがいくつかあります。

• パスワードの暗号化方法は何ですか？
• 標準的な認証と承認のプロセスは何ですか？
• トークン交換はどのように機能しますか（アクセストークン、リフレッシュトークン、IDトークンなど）？
• トークンに署名キーをどのように使用し、リソースを保護するために署名をどのように検証できますか？
• クライアントとサーバーの攻撃をどのように防ぐことができますか？

最後に、良好なサインイン体験を作成して顧客に提供することができます。

承認モデル#

書店として、顧客と販売者のリソースを分ける必要があります。例えば、顧客は全ての書籍を閲覧することができますが、売り手は自分の出品している書籍を管理できます。シンプルなif-elseチェックから始めるのは問題ありませんが、ビジネスが成長するにつれて、ロールベースのアクセス制御（RBAC）や属性ベースのアクセス制御（ABAC）のようなより柔軟なモデルを活用する必要が出てくるかもしれません。

私はまた、基本的な認可概念とRBACモデルを示す CIAM 102: Authorization & Role-based Access Controlという記事を書きました。

決定を下す#

認証は"全てまたは無し"の問題ではなく、複数の技術要素が関与し、あなたまたはあなたのチームはこれらの領域に異なる技術的専門知識を持つかもしれません。それを小さな部分に分解し、現状の理解を深めることが重要です。

決定を下すために、私は自分自身に以下の質問をします：

• プロジェクトはどれだけ緊急ですか？
• 認証に対してビジネスに対してどれだけの労力を想定していますか？
• ユーザーエクスペリエンス、セキュリティ、保守性の優先順位は何ですか？
• 私はどの部分を完全にコントロールする必要がありますか？それらについてどれだけ詳しくなるべきですか？
• フレームワーク / ソリューションを採用する場合、それらはカスタマイズや拡張のために十分に良いですか？
• ビジネスが成長すると、新しい認証モデルを導入する必要がありますか？
• 適したベンダーを見つけると、それを安全に使用することができますか？ベンダーに何か問題が発生した場合、撤退計画が必要ですか？

これらの質問を持って、私は以下の2つの事実を発見しました：

• 信頼できる認証システムを作り上げることは非常に複雑です。
• 既存のベンダーはすべての必要条件を満たすことができません。

したがって、認証のために専用のプロジェクト（Logto）を開始し、初日からオープンソースコミュニティを採用することを決定しました。

この記事が皆さんの役に立つことを願っています。