CIAM 101: 認証、アイデンティティ、SSO

背景#

私は、アイデンティティとアクセス管理 (IAM) が時を経てますます複雑で広範になったことに気付き、Logto の構築を始めました。IAM の概念はさらに大きく、WIAM (Workforce IAM) や CIAM (Customer IAM) などの新しい概念を生み出すほどです。

WIAM と CIAM は同じ基盤を共有していますが、使用例は異なります。WIAM は通常、内部ユーザーに使用され、CIAM は外部顧客に使用されます。 例:

• WIAM あなたの会社には従業員のための統一されたアイデンティティシステムがあり、誰もが同じアカウントを使用してソフトウェアのサブスクリプション、クラウドコンピューティングサービスなどの会社リソースにアクセスできます。
• CIAM あなたのオンライン書店は顧客と販売者のためのユーザーアイデンティティシステムを必要とします。サインインの体験はオンボーディングの重要な部分であり、コンバージョンファネルの最上部に位置します。

Logto は、さまざまな理由で CIAM を始めました（これについては別の記事でお話しします）。開発中、私たちは製品を次のレベルに引き上げる前に、チーム全体で統一した理解を構築することが有益であることに気付きました。これが IAM の世界をよりよく理解する助けになることを願っています。

始めましょう！

CIAM の基本#

この記事では、CIAM の基本的な概念と、認証フロー中や認証フロー後に直面する可能性のある問題に焦点を当てます。また、シングルサインオン (SSO) とその関連シナリオについても触れます。

認証と承認#

💡 認証は「あなたは誰ですか？」として初めに定義されます。しかし、デジタルアイデンティティについて議論する際には、「アイデンティティの所有を証明すること」で認証を示す方がより正確です。 (Calm-Card-2424 に感謝)

この 2 つのカテゴリーのいずれにも収まらないものを発見した場合、それはおそらくアイデンティティビジネスにとって本質的ではないでしょう。

• 認証の例
  • パスワードサインイン、パスワードレスサインイン、ソーシャルサインイン等。
  • マシン間の認証
• 承認の例
  • ロールベースアクセス制御
  • 属性ベースアクセス制御
• 例外の例
  • 非アイデンティティデータ
  • Web フック

アイデンティティとテナント#

アイデンティティは通常、ユーザーまたはマシンを表します。認証に成功すると、IDトークンがアイデンティティとして発行されます。

つまり、認証の主な目的はアイデンティティを取得することです。

テナントはアイデンティティのグループです:

「マルチテナント」について議論する際には、アイデンティティが互いに分離されている複数の Logto インスタンスを指しています。つまり、複数の Logto インスタンスです。

これは 2 つの 分離された アイデンティティシステムを持っていることを示しています。つまり、1 つのテナントのアイデンティティは別のテナントで使用できません。たとえ同じ識別子（メール、電話など）でもです。例えば、Costco のメンバーシップが Whole Foods では有効ではないのと同様です。

アプリとテナント#

アイデンティティと同様に、アプリもテナントに属します。覚えておくべきこと：

• アプリとアイデンティティの間に直接的な関係は通常ありません。
  • アプリはアイデンティティを表すことができますが、直接的な接続はありません。
• ユーザーと同様に、アプリもテナントレベルにあります。
• アプリはコードであり、ユーザーは人間です。
• アプリの唯一の目的は認証を完了すること、すなわちアイデンティティを取得することです。

アイデンティティプロバイダー (IdP) とサービスプロバイダー (SP)#

これら 2 つのプロバイダーの違いは微妙ですが重要です。

• アイデンティティプロバイダー は認証（AuthN）を提供し、アイデンティティを発行するサービスです。

Service Provider については Google からのさまざまな説明を見つけることができますが、満足のいくものではないかもしれません。私の考えでは、Service Provider は相対的な概念です：

• サービスプロバイダー（または OIDC のリライイングパーティ） は、認証（AuthN）を開始し、アイデンティティプロバイダーから結果を要求するサービスまたはクライアントです。

クイズ#

典型的なソーシャルサインインシナリオを考慮してください：

❓ この図にはいくつのサービスプロバイダーとアイデンティティプロバイダーがありますか？

答え

両方とも 2 です。iOS アプリは Logto のサービスプロバイダーであり、Logto はアイデンティティプロバイダーです。 Logto は GitHub に対するサービスプロバイダーでもあり、GitHub はアイデンティティプロバイダーです。従って、Logto は サービスプロバイダーおよびアイデンティティプロバイダーです。

ケーススタディ：テックソリューション会社#

あなたはテックソリューション会社の CTO であり、100 以上のビジネスパートナーを持ち、300 以上のプロジェクトを納品してきました。

• 各プロジェクトは Web アプリまたはモバイルアプリとバックエンドサービスのどちらかです。
• ビジネスパートナーごとに、プロジェクト間で SSO を提供するためにユーザーシステムをリファクタリングしたい。

❓ Logto（または CIAM 製品）はどのように役立ちますか？

答え

各ビジネスパートナーに Logto インスタンスを作成します。各パートナーがテナントを持ち、プロジェクトは Logto の「アプリ」にマッピングされます。

Logto はテナント内での普遍的なサインイン体験（すなわち SSO）を提供します。そのため、テナント内の別のアプリにアクセスする際にユーザーが既にサインインしている場合、再度サインインする必要はありません。

SSO の話題#

私たちは、「SSO」という用語がしばしば混乱を引き起こすことに気付きました。シングルサインオン (SSO) は行動であり、ビジネスの概念ではないと考えます。したがって、SSO は「WIAM の SSO」と等しくありません。

「SSO が必要です」というとき、それはいくつかのケースを指すことができます：

SSO ケース 1#

👉🏽 大企業では、従業員はすべての会社ライセンスリソース（例えば、メール、IM、クラウドサービス）にサインインするために同じ資格情報を使用します。

これは典型的な WIAM シナリオです。この場合、1 つのアイデンティティプロバイダーのみが関与します。今は気にしません。

SSO ケース 2#

👉🏽 エンドユーザーは、同じ会社が開発したすべてのサービス（例えば、GSuite）にサインインするために同じ資格情報を使用します。

Logto は現在、上記のアプローチに焦点を当てています。複数の外部アイデンティティプロバイダー、例えば第三者のソーシャルサインインプロバイダーが独立して存在し、関連性はありません。

それにもかかわらず、Logto はアイデンティティにとって唯一の信頼できる情報源として、他のプロバイダーからそれらを「借りる」だけです。この場合、Logto は GSuite アプリに対するアイデンティティプロバイダーでもあり、外部アイデンティティプロバイダーに対するサービスプロバイダーでもあります。

SSO ケース 3#

👉🏽 エンドユーザーは、特定のメールドメイン内の特定のアイデンティティプロバイダーのみを使用して認証を完了することができます。例えば、Google Workspace での Figma へのサインインです。

これは CIAM における SSO の最も一般的なユースケースです。詳しく見てみましょう。

@silverhand.io のメールを使って私たちが Figma にサインインしたい場合、ソーシャルサインインもしくは SSO を使用することができます。以下の図がその違いを示しています：

言葉で説明すると：

• ソーシャルサインイン後、ユーザーは Figma でパスワードを設定したりメールアドレスを変更することが自由にできます。
• SSO 後、ユーザーはパスワードを設定したり個人情報（含むメールアドレス）を変更することはできません。そのアイデンティティが Google Workspace によって管理されているためです。

このケースでは、Logto はアイデンティティプロバイダーでもあり、サービスプロバイダーでもあります。SSO は通常のサインインプロセスよりも複雑に見えます。アイデンティティ所有者にとって、どのような利点があるのでしょうか？

• 集中管理: アイデンティティ情報と認証プロセスを一元管理し、ユーザー情報が常に最新であることを確保できます。変更に応じて異なるアプリケーション間でライセンスを追加したり削除したりする必要はありません。
• 改善されたユーザー体験: SSO を必要とするアイデンティティ所有者は通常企業です。彼らの従業員は、Figma、Zoom、Slack など、会社間で一貫した資格情報と共有セッションを使用することができます。
• 強化されたセキュリティ: いくつかの企業が特定のサインイン方法、例えば動的な確認コードを要求することに気付いたかもしれません。SSO を使用すると、すべてのリソースへのアクセスに同じサインイン方法を組み合わせて使用することを確実にします。

🤔 あなたのような賢い人は、実際にこれは SaaS の視点から見た SSO ケース 1 であることに気付いたことでしょう。

SSO 図の「X」について議論する時が来ました。これは、Figma がメールドメインを特定のアイデンティティプロバイダーに接続するプロセスを表しています。しかし、どうやってそれが機能するのでしょうか？

SSO マッピング#

要求が通常企業クライアントから来るため、前のセクションの「SSO ケース 3」のプロセスを「Enterprise SSO」として明確にします。

単純なソリューションを考え出すことが容易です：メールドメインと SSO メソッドの間にマッピングを作成し、それを手動で更新します。

プロセス「X」のアクションが今明らかになりました：

🔍 指定されたメールドメインのマッピングされた Enterprise SSO メソッドを見つけます

数十のクライアントだけが Enterprise SSO を必要としている場合、そのマッピングを手動で管理することは問題ありません。しかし、もっと考慮すべきことがあります：

1. 数百または数千の Enterprise SSO クライアントがいる場合はどうしますか？
2. 「通常のユーザー」と「Enterprise SSO ユーザー」の関係はどうなりますか？
3. 異なる Enterprise SSO クライアント間でデータを分離する必要がありますか？
4. Enterprise SSO 管理者がアクティブなユーザー、監査ログなどを表示するためのダッシュボードを提供する必要がありますか？
5. Enterprise SSO アイデンティティプロバイダーからユーザーが削除されたときにアカウントを自動的に非アクティブ化する方法はありますか？

さらに多くがあります。ほぼすべての Enterprise SSO がメールドメインベースであることから、より良いソリューションを迅速に見つけることができます：

• ユーザーがそのドメインの所有を証明できる場合、そのドメインのエンタープライズ SSO を自己サービスで設定できるようにします。

このソリューションは、最初の 2 つの質問に対処しています：

1. 数百または数千の Enterprise SSO クライアントがいる場合はどうしますか？

• 彼らは自己サービスで Enterprise SSO を設定できます。

2. 「通常のユーザー」と「Enterprise SSO ユーザー」の関係はどうなりますか？

• 通常のユーザーには、Enterprise SSO 以外のすべてのサインインメソッドを開放し、そのドメインでサインインしようとしているユーザーには Enterprise SSO のサインインメソッドだけを制限します。

3 番目の質問については：

3. 異なる Enterprise SSO クライアント間でデータを分離する必要がありますか？

• はいといいえ。組織を紹介する時です。

組織#

特定の Enterprise SSO メソッドの使用を認識するためにメールドメインを使用することについて言及しました。つまり、特定のユーザーグループに特定の処理を適用すること。

しかし、クライアントの要求は通常、Enterprise SSO だけではありません。例えば、前のセクションでの質問 4 と 5 です。何年もの活動の中で、優れた SaaS 企業によってこの種の問題に対処するために成熟したモデルが開発されました：組織。

組織の規則

1. 組織は一般にテナントよりも小さいアイデンティティのグループです。
2. すべての組織はテナントに関連付けられています。

他の用語、例えば "Workspace"、”Team” もしくは "Tenant" をソフトウェアで見かけるかもしれません。それが私たちが議論している概念であるかどうかを確認するには、それが「アイデンティティのグループ」を代表しているかどうかを確認してください。

この説明の一貫性を保つために、本記事では「組織」という用語を使用します。

Notion では、同じメールアドレスで複数のワークスペース（つまり、組織）を作成し参加することができ、簡単にそれらの間を切り替えることができます。

Slack でも同じように見えますが、背後で異なるアイデンティティが使用されていると疑われます。なぜなら、各ワークスペースに対して新しいアカウントを作成する必要があるからです。

Notion には「Personal Plan」があり、通常は内部的に唯一のユーザー（あなた）が含まれる組織です。Notion の正確な実装は分かりませんが、この説明は合理的であり、私たちのモデルに対して実現可能です。

各組織にも識別子があり、通常「組織ドメイン」と呼ばれます。

クイズ#

❓ アプリは組織に関連付けることができますか？

答え

はい、できます。冒頭でお話ししたように、アプリはアイデンティティを持つことができます。これについて ビジネスシナリオを詳しく説明できますか？

残された質問#

3. 異なる Enterprise SSO クライアント間でデータを分離する必要がありますか？

• はい: ビジネスデータ、例えばメッセージやドキュメントを組織レベルで分離します。
• いいえ: アイデンティティを独立させる、それらは組織に関連する必要はありません。
• ここでは 3 つの異なるエンティティ、アイデンティティ、組織、および Enterprise SSO 構成が関与しています；これは特に複雑さを増したものです。質問自体が具体的ではありません。

4. Enterprise SSO 管理者がアクティブなユーザー、監査ログなどを表示するためのダッシュボードを提供する必要がありますか？

5. Enterprise SSO アイデンティティプロバイダーからユーザーが削除されたときにアカウントを自動的に非アクティブ化する方法は？

• これらの要求はよりビジネス志向であり、組織レベルで実装することができます。ここではそれらを開いたままにしておきます。

終わりに#

以下のようないくつかの概念を紹介しました：認証 (AuthN)、承認 (AuthZ)、アイデンティティ、テナント、アプリケーション、アイデンティティプロバイダー (IdP)、サービスプロバイダー (SP)、シングルサインオン (SSO)、および Enterprise SSO (組織)。これらすべてを理解するには時間がかかるかもしれません。

この記事を書いている間に興味深いことに気付いたことは、オンラインサービスの最も高価なプランには通常、ここではまったく言及されていない、承認に関連する特有の機能が含まれていることです。あなたはすでに承認についていくつかの質問を持っているかもしれません：

• どのようにしてユーザーに許可を割り当て、それを検証することができますか？
• どの承認モデルを使用すべきですか？
• 承認モデルを適用するためのベストプラクティスは何ですか？