日本語
アプリのために自分で認証を作成する必要がありますか？
「私は、自分のアプリのために自分で認証を作成すべきですか？」と疑問を抱く開発者が多いことに気づいています。答えは単純な "はい" や "いいえ" であるわけではありませんが、私はこの実装を分解し、利点と欠点を示す記事を書こうと思います。これにより、あなたが決断するのに役立てることができます。
Gao
Founder
Founder
「私は、自分のアプリのために自分で認証を作成すべきですか？」と疑問を抱く開発者が多いことに気づいています。答えは単純な "はい" や "いいえ" であるわけではありませんが、私はこの実装を分解し、利点と欠点を示す記事を書こうと思います。これにより、あなたが決断するのに役立てることができます。
「私のアプリのために自分で認証を作成すべきですか？」という質問をする開発者が多く見受けられます。答えは単純な"はい"や"いいえ"ではないので、実装を分解して利点と欠点を示す記事を書いて、あなたが決定を下すのを助けたいと思います。
要約 あなたのニーズに合った既存の解決策を見つけることが必要です、全面的なコントロールを望むか、ソフトウェア開発をまだ学んでいるのであればです。
開発者として、私はこれまでに多くのアプリケーションを構築してきました。使用するプログラミング言語に関係なく、常に構築する必要がある共通の基盤があります：ユーザー認証。
20年前にはすべてが明確で、それは取るに足らない部分でした。
それで十分でした。その後、「本業」に集中することができました。 MD5について知らない？ソフトウェア開発の「良い時代」を逃しました。現在、開発者はログイン/アップを構築する際にさらなる課題に直面しています。
それは危機的に聞こえるかもしれませんが、私が一つ例を通して詳しく説明します。
APIサービスとWebフロントエンドアプリを持つオンライン書店を構築しようとしているとしましょう。
まず、"認証"の範囲を定義する必要があります。認証は認証と承認として説明でき、それらは全く異なる定義と使用例を持っています。
これらの概念を詳しく議論するために、CIAM 101: Authentication, Identity, SSOという記事を書きました。
我々の例であるユーザーサインインで"認証"を開始しましょう。ユーザー名とパスワードの方法以外に、ユーザーのコンバージョンやセキュリティを向上させるために採用されているトレンドの方法がいくつかあります。
方法の選択はビジネス判断に依存しますが、技術努力については次のように考えることができます。
[email protected] のGmailアカウントでログインすると、このメールアドレスを書店のユーザー foo にリンクできます。これにより、あなたは統一したアイデンティティシステムを構築でき、ユーザーは将来的に社会的アイデンティティを変更하거うにリンクすることができます。認証方法を決定した後、エンドユーザーにとって円滑でスムーズなログイン体験が次のターゲットです。ここでのコンバージョンは基本的ですが、事業にとっては重要です。なぜなら、それは顧客データを維持する自然な方法だからです。
Airbnbで働いていた時、サインイン体験を多数プラットホームで最適化するために専用のチームがありました。彼らは、どの組み合わせが最高のコンバージョン率を持つかを判断するために、多数のA / Bテストを実施しました。
ビジネスが始まったばかりのときにそうするのは実用的ではありません。しかし、私たちはまだ最善を尽くしてすべての部品を作る必要があります。書店を運営したいプラットフォームは何ですか？モバイルを始めたり、ウェブから始めたり、両方を始めたりすることができます。具体的な設計は、選択した認証方法に依存します。
それをより良くするために考慮すべき他のこと：
ネイティブ開発を選択すると、追加のプラットフォームに対する作業量はほぼ倍増します。
セキュリティは見えない氷山となる可能性があります。OpenID ConnectまたはOAuth 2.0に詳しいのであれば、それは素晴らしいです。広く使用され、実戦検証されています。OpenID Connectは比較的新しいですが、「ユーザー認証」に設計されているため、オンライン書店に適しています。
スタンダードの詳細に入ることなく、まだ考慮するべきことがいくつかあります。
最後に、良好なサインイン体験を作成して顧客に提供することができます。
書店として、顧客と販売者のリソースを分ける必要があります。例えば、顧客は全ての書籍を閲覧することができますが、売り手は自分の出品している書籍を管理できます。シンプルなif-elseチェックから始めるのは問題ありませんが、ビジネスが成長するにつれて、ロールベースのアクセス制御（RBAC）や属性ベースのアクセス制御（ABAC）のようなより柔軟なモデルを活用する必要が出てくるかもしれません。
私はまた、基本的な認可概念とRBACモデルを示す CIAM 102: Authorization & Role-based Access Controlという記事を書きました。
認証は"全てまたは無し"の問題ではなく、複数の技術要素が関与し、あなたまたはあなたのチームはこれらの領域に異なる技術的専門知識を持つかもしれません。それを小さな部分に分解し、現状の理解を深めることが重要です。
決定を下すために、私は自分自身に以下の質問をします：
これらの質問を持って、私は以下の2つの事実を発見しました：
したがって、認証のために専用のプロジェクト（Logto）を開始し、初日からオープンソースコミュニティを採用することを決定しました。
この記事が皆さんの役に立つことを願っています。