CIAM 101: 認証、アイデンティティ、SSO
Logto はさまざまな理由で CIAM を始めました(これについて別の記事でお話しします)。開発中、チーム内での統一した理解を構築することが、製品を次のレベルに引き上げる前に有益であることに気付きました。これが IAM の世界をより良く理解する助けになることを願っています。
Logto はさまざまな理由で CIAM を始めました(これについて別の記事でお話しします)。開発中、チーム内での統一した理解を構築することが、製品を次のレベルに引き上げる前に有益であることに気付きました。これが IAM の世界をより良く理解する助けになることを願っています。
私は、アイデンティティとアクセス管理 (IAM) が時を経てますます複雑で広範になったことに気付き、Logto の構築を始めました。IAM の概念はさらに大きく、WIAM (Workforce IAM) や CIAM (Customer IAM) などの新しい概念を生み出すほどです。
WIAM と CIAM は同じ基盤を共有していますが、使用例は異なります。WIAM は通常、内部ユーザーに使用され、CIAM は外部顧客に使用されます。 例:
Logto は、さまざまな理由で CIAM を始めました(これについては別の記事でお話しします)。開発中、私たちは製品を次のレベルに引き上げる前に、チーム全体で統一した理解を構築することが有益であることに気付きました。これが IAM の世界をよりよく理解する助けになることを願っています。
始めましょう!
この記事では、CIAM の基本的な概念と、認証フロー中や認証フロー後に直面する可能性のある問題に焦点を当てます。また、シングルサインオン (SSO) とその関連シナリオについても触れます。
💡 認証は「あなたは誰ですか?」として初めに定義されます。しかし、デジタルアイデンティティについて議論する際には、「アイデンティティの所有を証明すること」で認証を示す方がより正確です。 (Calm-Card-2424 に感謝)
この 2 つのカテゴリーのいずれにも収まらないものを発見した場合、それはおそらくアイデンティティビジネスにとって本質的ではないでしょう。
アイデンティティは通常、ユーザーまたはマシンを表します。認証に成功すると、IDトークンがアイデンティティとして発行されます。
つまり、認証の主な目的はアイデンティティを取得することです。
テナントはアイデンティティのグループです:
「マルチテナント」について議論する際には、アイデンティティが互いに分離されている複数の Logto インスタンスを指しています。つまり、複数の Logto インスタンスです。
これは 2 つの 分離された アイデンティティシステムを持っていることを示しています。つまり、1 つのテナントのアイデンティティは別のテナントで使用できません。たとえ同じ識別子(メール、電話など)でもです。例えば、Costco のメンバーシップが Whole Foods では有効ではないのと同様です。
アイデンティティと同様に、アプリもテナントに属します。覚えておくべきこと:
これら 2 つのプロバイダーの違いは微妙ですが重要です。
Service Provider については Google からのさまざまな説明を見つけることができますが、満足のいくものではないかもしれません。私の考えでは、Service Provider は相対的な概念です:
典型的なソーシャルサインインシナリオを考慮してください:
❓ この図にはいくつのサービスプロバイダーとアイデンティティプロバイダーがありますか?
答え
両方とも 2 です。iOS アプリは Logto のサービスプロバイダーであり、Logto はアイデンティティプロバイダーです。
Logto は GitHub に対するサービスプロバイダーでもあり、GitHub はアイデンティティプロバイダーです。従って、Logto は
サービスプロバイダーおよびアイデンティティプロバイダーです。
あなたはテックソリューション会社の CTO であり、100 以上のビジネスパートナーを持ち、300 以上のプロジェクトを納品してきました。
❓ Logto(または CIAM 製品)はどのように役立ちますか?
各ビジネスパートナーに Logto インスタンスを作成します。各パートナーがテナントを持ち、プロジェクトは Logto の「アプリ」にマッピングされます。
Logto はテナント内での普遍的なサインイン体験(すなわち SSO)を提供します。そのため、テナント内の別のアプリにアクセスする際にユーザーが既にサインインしている場合、再度サインインする必要はありません。
私たちは、「SSO」という用語がしばしば混乱を引き起こすことに気付きました。シングルサインオン (SSO) は行動であり、ビジネスの概念ではないと考えます。したがって、SSO は「WIAM の SSO」と等しくありません。
「SSO が必要です」というとき、それはいくつかのケースを指すことができます:
👉🏽 大企業では、従業員はすべての会社ライセンスリソース(例えば、メール、IM、クラウドサービス)にサインインするために同じ資格情報を使用します。
これは典型的な WIAM シナリオです。この場合、1 つのアイデンティティプロバイダーのみが関与します。今は気にしません。
👉🏽 エンドユーザーは、同じ会社が開発したすべてのサービス(例えば、GSuite)にサインインするために同じ資格情報を使用します。
Logto は現在、上記のアプローチに焦点を当てています。複数の外部アイデンティティプロバイダー、例えば第三者のソーシャルサインインプロバイダーが独立して存在し、関連性はありません。
それにもかかわらず、Logto はアイデンティティにとって唯一の信頼できる情報源として、他のプロバイダーからそれらを「借りる」だけです。この場合、Logto は GSuite アプリに対するアイデンティティプロバイダーでもあり、外部アイデンティティプロバイダーに対するサービスプロバイダーでもあります。
👉🏽 エンドユーザーは、特定のメールドメイン内の特定のアイデンティティプロバイダーのみを使用して認証を完了することができます。例えば、Google Workspace での Figma へのサインインです。
これは CIAM における SSO の最も一般的なユースケースです。詳しく見てみましょう。
@silverhand.io のメールを使って私たちが Figma にサインインしたい場合、ソーシャルサインインもしくは SSO を使用することができます。以下の図がその違いを示しています:
ソーシャルサインイン
SSO
言葉で説明すると:
このケースでは、Logto はアイデンティティプロバイダーでもあり、サービスプロバイダーでもあります。SSO は通常のサインインプロセスよりも複雑に見えます。アイデンティティ所有者にとって、どのような利点があるのでしょうか?
🤔 あなたのような賢い人は、実際にこれは SaaS の視点から見た SSO ケース 1 であることに気付いたことでしょう。
SSO 図の「X」について議論する時が来ました。これは、Figma がメールドメインを特定のアイデンティティプロバイダーに接続するプロセスを表しています。しかし、どうやってそれが機能するのでしょうか?
要求が通常企業クライアントから来るため、前のセクションの「SSO ケース 3」のプロセスを「Enterprise SSO」として明確にします。
単純なソリューションを考え出すことが容易です:メールドメインと SSO メソッドの間にマッピングを作成し、それを手動で更新します。
プロセス「X」のアクションが今明らかになりました:
🔍 指定されたメールドメインのマッピングされた Enterprise SSO メソッドを見つけます
数十のクライアントだけが Enterprise SSO を必要としている場合、そのマッピングを手動で管理することは問題ありません。しかし、もっと考慮すべきことがあります:
さらに多くがあります。ほぼすべての Enterprise SSO がメールドメインベースであることから、より良いソリューションを迅速に見つけることができます:
このソリューションは、最初の 2 つの質問に対処しています:
1. 数百または数千の Enterprise SSO クライアントがいる場合はどうしますか?
2. 「通常のユーザー」と「Enterprise SSO ユーザー」の関係はどうなりますか?
3 番目の質問については:
3. 異なる Enterprise SSO クライアント間でデータを分離する必要がありますか?
特定の Enterprise SSO メソッドの使用を認識するためにメールドメインを使用することについて言及しました。つまり、特定のユーザーグループに特定の処理を適用すること。
しかし、クライアントの要求は通常、Enterprise SSO だけではありません。例えば、前のセクションでの質問 4 と 5 です。何年もの活動の中で、優れた SaaS 企業によってこの種の問題に対処するために成熟したモデルが開発されました:組織。
組織の規則
他の用語、例えば "Workspace"、”Team” もしくは "Tenant" をソフトウェアで見かけるかもしれません。それが私たちが議論している概念であるかどうかを確認するには、それが「アイデンティティのグループ」を代表しているかどうかを確認してください。
この説明の一貫性を保つために、本記事では「組織」という用語を使用します。
Notion では、同じメールアドレスで複数のワークスペース(つまり、組織)を作成し参加することができ、簡単にそれらの間を切り替えることができます。
Slack でも同じように見えますが、背後で異なるアイデンティティが使用されていると疑われます。なぜなら、各ワークスペースに対して新しいアカウントを作成する必要があるからです。

Slack ワークスペース

Notion ワークスペース
Notion には「Personal Plan」があり、通常は内部的に唯一のユーザー(あなた)が含まれる組織です。Notion の正確な実装は分かりませんが、この説明は合理的であり、私たちのモデルに対して実現可能です。
各組織にも識別子があり、通常「組織ドメイン」と呼ばれます。
❓ アプリは組織に関連付けることができますか?
答え
はい、できます。冒頭でお話ししたように、アプリはアイデンティティを持つことができます。これについて
ビジネスシナリオを詳しく説明できますか?
3. 異なる Enterprise SSO クライアント間でデータを分離する必要がありますか?
4. Enterprise SSO 管理者がアクティブなユーザー、監査ログなどを表示するためのダッシュボードを提供する必要がありますか?
5. Enterprise SSO アイデンティティプロバイダーからユーザーが削除されたときにアカウントを自動的に非アクティブ化する方法は?
以下のようないくつかの概念を紹介しました:認証 (AuthN)、承認 (AuthZ)、アイデンティティ、テナント、アプリケーション、アイデンティティプロバイダー (IdP)、サービスプロバイダー (SP)、シングルサインオン (SSO)、および Enterprise SSO (組織)。これらすべてを理解するには時間がかかるかもしれません。
この記事を書いている間に興味深いことに気付いたことは、オンラインサービスの最も高価なプランには通常、ここではまったく言及されていない、承認に関連する特有の機能が含まれていることです。あなたはすでに承認についていくつかの質問を持っているかもしれません: