# シングルサインオン {#single-sign-on}

Tuist は、組織のアカウントセキュリティを強化するためのログインオプションとしてシングルサインオンを提供します。

シングルサインオンは、組織設定の **認証** タブから構成します。Google Workspace、Okta、Microsoft Entra ID、およびカスタムの [OAuth 2.0](https://oauth.net/2/) プロバイダーがサポートされています。

Microsoft Entra ID は、ディレクトリ識別子に基づいて Tuist が構成する OpenID Connect プロバイダーです。このガイドでカスタムプロバイダーについて説明している内容（ログイン用メールドメインの検証やエンロールメントなど）は、すべて Microsoft Entra ID にも適用されます。

> [!NOTE]
> シングルサインオンは、メンバーの認証方法と、認証済みユーザーが自動的に参加できるかどうかを制御します。<.localized_link href="/guides/integrations/authentication/scim">System for Cross-domain Identity Management provisioning</.localized_link> は、ID プロバイダーが組織メンバーを作成、更新、およびプロビジョニング解除できるかどうかを制御します。Okta の場合、ほとんどの組織で両方を構成します。

## アクセスの仕組み {#how-access-works}

プロバイダーの発行元、ログインの検出、組織へのエンロールメントはそれぞれ独立した概念です。

- **プロバイダーの発行元:** ユーザーを認証したプロバイダー組織または認可サーバーです。Tuist は、リンクされた ID を検索する際に、プロバイダー、発行元、および安定したプロバイダーユーザー識別子を組み合わせます。Okta の場合、発行元は Okta ドメインで表されます。Microsoft Entra ID の場合、ディレクトリ（テナント）識別子から導出されます。カスタムプロバイダーの場合、プロバイダー URL で表されます。
- **ログイン用メールドメイン:** Tuist が一般的なログインページから Okta またはカスタムプロバイダーを検出するために使用するメールドメインです。検証が完了すると、新しいアカウントのリンクと自動エンロールメントのために信頼できるメールアドレスも確立されます。
- **エンロールメントポリシー:** 信頼されたドメインのユーザーが招待を必要とするか、自動的に参加できるかを決定します。
- **プロビジョニング:** ログインフローとは独立して組織メンバーシップを作成および管理します。

プロバイダーの発行元とログイン用メールドメインは異なることがよくあります。たとえば、企業は従業員用のメールに `example.com` を使用しつつ、プロバイダーの発行元が `https://login.vendor.example.net` である場合があります。新しい Okta およびカスタムプロバイダーの構成では、これらの値は別々に保存されます。

### ログイン用メールドメインを検証する {#verify-a-login-email-domain}

Okta およびカスタムプロバイダーの構成では、新しい Tuist アカウントを作成したり、既存のアカウントをメールアドレスでリンクしたりする前に、ログイン用メールドメインの検証が必要です。ドメインが未検証の間でも、メンバーは <.localized_link href="/guides/integrations/authentication/sso#link-an-existing-account">既存のアカウントをリンク</.localized_link> できます。

1. **ログイン用メールドメイン** に、`example.com` などの従業員用メールドメインを入力します。
2. シングルサインオンの構成を保存します。
3. Tuist が表示する TXT レコードを、ドメインの [Domain Name System](https://www.cloudflare.com/learning/dns/dns-records/dns-txt-record/) 構成に追加します。
4. 認証設定に戻り、**ドメインを検証** をクリックします。

検証済みのログイン用メールドメインは、1 つの Tuist 組織にのみ属することができます。ドメインを変更すると検証がクリアされ、新しい TXT レコードの公開が必要になります。ドメインが検証されるまで、自動エンロールメントは一時停止されたままです。

Tuist は毎日 TXT レコードを再確認します。レコードの解決が停止しても、検証は直ちにクリアされません。ドメインは 14 日間保持し、認証設定には **検証の有効期限切れ** と、再度公開すべきレコードが表示されます。レコードを公開して検証を行うと、警告は消えます。14 日後もレコードが見つからないドメインは未検証の状態に戻り、プロバイダーの検出、ID のリンク、自動エンロールメントは、再び検証されるまで停止します。他の理由でルックアップが失敗しても、タイマーはリセットされず、検証自体はクリアされません。毎日の再確認が導入される前に検証されたドメインは、再確認の対象ではありません。

Google は認証済み ID の一部として検証済みの Workspace ドメインを提供するため、Google Workspace ではこの個別の Tuist 検証手順は不要です。

### エンロールメントポリシーを選択する {#choose-an-enrollment-policy}

Tuist は 2 つのエンロールメントポリシーをサポートしています。

- **招待のみ:** ユーザーには組織への招待が必要です。Okta およびカスタムプロバイダーの場合、プロバイダーが新しい Tuist アカウントを作成するには、ログイン用メールドメインの検証が依然として必要です。既存の Tuist アカウントを持つ招待されたユーザーは、まず招待を受け入れ、その後 <.localized_link href="/guides/integrations/authentication/sso#link-an-existing-account">既存の Tuist アカウントをリンク</.localized_link> で説明されているようにプロバイダー ID をリンクします。
- **自動:** 認証されたメールが信頼されたドメインと一致するユーザーは、招待なしでアカウントを作成またはリンクし、組織に参加できます。Google の構成では Workspace ドメインを使用します。Okta およびカスタムプロバイダーでは、検証済みのログイン用メールドメインが必要です。

Google の構成では、デフォルトで自動エンロールメントが有効になっています。新しい Okta およびカスタムプロバイダーの構成では、デフォルトで招待のみによるエンロールメントが有効になっています。

**シングルサインオンを強制** 設定は、エンロールメントとは独立しています。強制を有効にすると、既存の組織メンバーはメールとパスワードを使用したログインができなくなります。ただし、これによって組織メンバーシップが付与されるわけではありません。

### エンロールされたメンバーに付与されるロールを選択する {#choose-the-enrollment-role}

自動的に参加したメンバーには、**エンロールされたメンバーのロール** で設定された <.localized_link href="/guides/server/accounts-and-projects#roles">ロール</.localized_link> が付与されます。管理者が変更しない限り、これは `user` です。`viewer` に設定すると、ディレクトリ内の全員がサインインできるようになりますが、全員に変更権限が付与されるわけではありません。

この設定を `admin` にすることはできません。また、ロールなしで <.localized_link href="/guides/integrations/authentication/scim">SCIM</.localized_link> 経由でプロビジョニングされたメンバーおよびサインインするメンバーに適用され、管理者が手動で設定したロールを上書きすることはありません。

### 既存の Tuist アカウントをリンクする {#link-an-existing-account}

リンクされたプロバイダー ID は、そのアカウントが属する他のすべての組織を含め、Tuist アカウント全体にサインインします。Okta およびカスタムプロバイダーの場合、Tuist は、メールアドレスが検証済みのログイン用メールドメインにある場合、または組織の SCIM プロビジョニングによってアカウントが作成された場合にのみ、既存のアカウントを自動的にリンクします。

資格のないアカウントを持つメンバーは、自身で ID をリンクします。

1. アカウントの通常のサインイン方法を使用して Tuist にログインします。
2. ID プロバイダー（アプリケーションタイルなど）から Tuist を開くか、シングルサインオンを強制している場合は組織のプロジェクトの 1 つを開きます。
3. Tuist が表示する組織と ID プロバイダーのアカウントを確認し、**アカウントをリンク** をクリックします。

サインアウト状態でシングルサインオンを開始したメンバーは、まずログインを求められ、その後 Tuist が確認画面に戻ります。リンクはドメインの検証に依存しないため、ドメインが検証される前でもメンバーはシングルサインオンを使用できます。

### 既存の組織 {#existing-organizations}

すべての Okta およびカスタムプロバイダー組織は、検証済みドメインモデルを使用します。一時的な互換性モードは削除されました。

ログイン用メールドメインが未検証の場合：

- 既存のリンク済みメンバーは引き続きサインインでき、既存の SSO 強制設定は組織メンバーに引き続き適用されます。
- ログインページは、既存の組織メンバーシップのみを通じてプロバイダーを検出します。
- 自動エンロールメントは一時停止され、プロバイダーは招待があっても新しい Tuist アカウントを作成できません。
- リンクされていないメンバーは、既存の Tuist アカウントにサインインし、上記の手順に従ってリンクを確認します。組織の SCIM プロビジョニングによって作成されたアカウントは、最初の SSO サインイン時にもリンクできます。
- 新しいサインアップ者は、メールアドレスがあなたのドメインを使用しているという理由だけで、あなたのプロバイダーを使用する必要はありません。

既存の有効なエンロールメントおよび強制設定は保存されたままになり、無効にすることができます。管理者はドメインが未検証の間も構成を編集できますが、いずれかの設定を有効にするには検証が必要です。その設定が有効な場合、検証により一致するメールアドレスに対する自動エンロールメントが再開されます。Google Workspace の動作は変更されません。

**ログイン用メールドメイン** は、組織のメンバー情報からすでに入力されている可能性があります。値を確認し、テキストレコードを公開して、**ドメインを検証** をクリックします。毎日再チェックを行うため、レコードは公開された状態に保ってください。

## Google Workspace {#google}

Google Workspace のシングルサインオンは、Workspace ドメインに対してユーザーを認証します。管理者は、一致するユーザーの自動参加を許可するか、招待を必須にするかを選択できます。

> [!NOTE]
> **前提条件**
>
> 検証済みドメインを持つ Google Workspace 組織が必要です。また、設定しようとしているドメインに関連付けられたメールアドレスを使用して Google で認証されている必要があります。

### セットアップ {#google-setup}

1. 組織の **認証** 設定タブに移動します。
2. シングルサインオンを有効にします。
3. プロバイダーとして **Google** を選択します。
4. Google Workspace ドメイン（例：`example.com`）を入力します。
5. **自動エンロールメント** または招待のみによるエンロールメントを選択します。Google の場合、デフォルトで自動エンロールメントが有効になっています。
6. オプションで、ログインフローをテストした後、**シングルサインオンを強制** を有効にします。
7. **変更を保存** をクリックします。

## Okta {#okta}

Okta は [OpenID Connect](https://openid.net/developers/how-connect-works/) を使用してメンバーを認証します。Okta ドメインはプロバイダーの発行者を識別し、別途検証されたログイン用メールドメインは検出、新しいアカウントのリンク、およびエンロールメントを制御します。

Okta によるメンバーの自動作成、更新、またはプロビジョニング解除も行いたい場合は、シングルサインオンが機能している状態で <.localized_link href="/guides/integrations/authentication/scim#okta">Okta System for Cross-domain Identity Management provisioning</.localized_link> を構成してください。

### ステップ 1: Okta アプリケーションを作成する {#okta-step-1}

1. Okta 管理ダッシュボードで、**Applications > Applications > Create App Integration** に移動します。
2. **OpenID Connect** と **Web Application** を選択します。
3. アプリケーション名（例：`Tuist`）を設定します。オプションで [Tuist ロゴ](https://tuist.dev/images/tuist_dashboard.png) をアップロードします。
4. **Sign-in redirect URI** を認証設定ページに表示されている値（例：`https://tuist.dev/users/auth/okta/callback`）に設定します。
5. **Assignments** で、必要なアクセス制御を選択して保存します。
6. アプリケーションの一般設定から **Client ID** と **Client Secret** をコピーします。**Okta ドメイン**（例：`your-company.okta.com`）をメモします。
7. オプションで、Okta ダッシュボードからのログインを許可するには、General Settings で **Edit** をクリックし、**Login initiated by** を **Either Okta or App** に変更し、**Display application icon to users** を選択して、**Initiate login URI** を認証設定ページに表示されている値に設定します。

### ステップ 2: Tuist を構成する {#okta-step-2}

1. 組織の **認証** 設定タブに移動します。
2. シングルサインオンを有効にします。
3. プロバイダーとして **Okta** を選択します。
4. **Okta ドメイン**、**Client ID**、および **Client Secret** を入力します。
5. **ログイン用メールドメイン** に従業員のメールドメインを入力します。例えば、Okta ドメインが `your-company.okta.com` の場合、ログイン用メールドメインは `example.com` になります。
6. **変更を保存** をクリックします。
7. Tuist が表示する TXT レコードをログイン用メールドメインに追加し、**ドメインを検証** をクリックします。
8. ユーザーに招待が必要か、自動エンロールメントを許可するかを選択し、構成を再度保存します。
9. ログインフローをテストした後、オプションで **シングルサインオンを強制** を有効にします。

### ステップ 3: ユーザーを Okta アプリケーションに割り当てる {#okta-step-3}

Okta アプリケーションを通じて認証を許可されるユーザーまたはグループを割り当てます。

割り当てによりログインフローへのアクセス権が付与されますが、組織のメンバーシップは引き続きエンロールメントポリシーに従います。同じユーザーが System for Cross-domain Identity Management 経由でプロビジョニングされている場合、Tuist はユーザーが最初にサインインした際に、SCIM が作成したアカウントに Okta の ID をリンクします。SCIM によって追加される前にアカウントが存在していたメンバーの場合、そのメールアドレスが検証済みのログイン用メールドメインに含まれているか、サインイン済みのアカウントからリンクを確認した時点でリンクされます。

## Microsoft Entra ID {#microsoft-entra-id}

Microsoft Entra ID は [OpenID Connect](https://openid.net/developers/how-connect-works/) を介してメンバーを認証します。Tuist はディレクトリ（テナント）識別子から承認、トークン、およびユーザー情報エンドポイントを導出するため、アプリケーションの認証情報とともにその値を入力するだけで済みます。

Entra ID によるメンバーの自動作成、更新、またはプロビジョニング解除も行いたい場合は、シングルサインオンが機能している状態で <.localized_link href="/guides/integrations/authentication/scim#microsoft-entra-id">Microsoft Entra ID System for Cross-domain Identity Management provisioning</.localized_link> を構成してください。

### ステップ 1: Entra アプリケーションを登録する {#entra-step-1}

1. [Microsoft Entra 管理センター](https://entra.microsoft.com) で、**Identity > Applications > App registrations > New registration** に移動します。
2. アプリケーション名（例：`Tuist`）を設定します。
3. **Redirect URI** で **Web** プラットフォームを選択し、認証設定ページに表示されている値（例：`https://tuist.dev/users/auth/oauth2/callback`）を入力します。
4. アプリケーションを登録し、概要ページから **Directory (tenant) ID** と **Application (client) ID** をコピーします。
5. **Certificates & secrets > New client secret** に移動し、シークレットを作成してその **Value** をコピーします。Microsoft はこの値を一度しか表示せず、すべてのクライアントシークレットには有効期限があるため、回転が必要な時期を記録しておきます。
6. **API permissions** に移動し、委任された Microsoft Graph 権限 `openid`、`profile`、および `email` が付与されていることを確認します。
7. オプションで、メンバーが My Apps ポータルからサインインフローを開始できるようにするには、**Branding & properties** の **Home page URL** を認証設定ページに表示されている値に設定します。

### ステップ 2: Tuist を構成する {#entra-step-2}

1. 組織の **認証** 設定タブに移動します。
2. シングルサインオンを有効にします。
3. プロバイダーとして **Microsoft Entra ID** を選択します。
4. **Directory (tenant) ID**、**Client ID**、および **Client Secret** を入力します。
5. **ログイン用メールドメイン** に従業員のメールドメインを入力します。例えば、ユーザーが `first.last@example.com` としてサインインするディレクトリの場合、ログイン用メールドメインは `example.com` になります。
6. **変更を保存** をクリックします。
7. Tuist が表示する TXT レコードをログイン用メールドメインに追加し、**ドメインを検証** をクリックします。
8. ユーザーに招待が必要か、自動エンロールメントを許可するかを選択し、構成を再度保存します。
9. ログインフローをテストした後、オプションで **シングルサインオンを強制** を有効にします。

### ステップ 3: ユーザーを Entra アプリケーションに割り当てる {#entra-step-3}

認証を許可されるユーザーまたはグループを割り当てます。アプリケーションが割り当てを必須とするように構成されている場合、割り当てられたユーザーのみがサインインできます。

割り当てによりログインフローへのアクセス権が付与されますが、組織のメンバーシップは引き続きエンロールメントポリシーに従います。同じユーザーが System for Cross-domain Identity Management 経由でプロビジョニングされている場合、Tuist はユーザーが最初にサインインした際に、SCIM が作成したアカウントに Entra の ID をリンクします。SCIM によって追加される前にアカウントが存在していたメンバーの場合、そのメールアドレスが検証済みのログイン用メールドメインに含まれているか、サインイン済みのアカウントからリンクを確認した時点でリンクされます。

### email クレームの要件 {#entra-email-claim}

Tuist は Microsoft Graph のユーザー情報エンドポイントから認証済みユーザーのプロファイルを読み取ります。このエンドポイントは、ユーザーに利用可能なメールアドレスがある場合にのみそれを返します。`mail` 属性が空のディレクトリユーザーは、Tuist がログイン用メールドomainと照合するアドレスを持たないため、サインインできません。

シングルサインオンを展開する前に、割り当てたメンバーのメールアドレスがディレクトリに入力されていることを確認します。メールボックスのないオンプレミス Active Directory から同期されたユーザーは、この属性が欠落している最も一般的なケースです。

### 条件付きアクセスと多要素認証 {#entra-conditional-access}

条件付きアクセスポリシー、多要素認証、およびサインインリスクポリシーは、承認リクエスト中に評価されるため、他の Entra アプリケーションと同様に Tuist アプリケーションにも適用されます。追加の Tuist 構成は必要ありません。

## カスタム OAuth 2.0 プロバイダー {#custom-oauth-2-provider}

カスタム OAuth 2.0 プロバイダーを使用すると、組織は Google Workspace や Okta 以外の ID サービスを利用できます。プロバイダーのユーザー情報エンドポイントは、安定したユーザー識別子とメールアドレスを返す必要があります。

1. プロバイダーで OAuth 2.0 Web アプリケーションを作成します。
2. Tuist の認証設定に表示されている値に合わせて、**サインインリダイレクト URI** とオプションの **ログイン開始 URI** を設定します。
3. Tuist でシングルサインオンを有効にし、**OAuth2** を選択します。
4. プロバイダー URL、承認エンドポイント、トークンエンドポイント、ユーザー情報エンドポイント、クライアント識別子、およびクライアントシークレットを入力します。
5. **ログイン用メールドメイン** を入力して保存します。これは従業員のメールドメインであり、プロバイダー URL ではありません。
6. Tuist が表示する TXT レコードをログイン用メールドメインに追加し、**ドメインを確認** をクリックします。
7. 招待制または自動登録のいずれかを選択し、構成を保存します。
8. オプションで **シングルサインオンを強制** を有効にする前に、サインインをテストします。

プロバイダー URL は、発行元プロバイダーに対して ID をスコープ限定します。検証済みのログイン用メールドメインは、ユーザーのリンクや登録時に Tuist が信頼するメールアドレスを決定します。

## コマンドライン構成 {#command-line-configuration}

コマンドラインインターフェースを使用すると、Google Workspace または Okta を構成し、登録ポリシーを選択できます。例:

```bash
tuist organization update sso example \
  --provider okta \
  --organization-id your-company.okta.com \
  --enrollment-policy invitation-only
```

Microsoft Entra ID とカスタムプロバイダーは、コマンドラインではなく組織の認証設定から構成します。

`--organization-id` の値はプロバイダー組織を識別します。これはログイン用メールドメインではありません。新しい Okta ユーザーを登録する前に、組織の認証設定からログイン用メールドメインを追加して検証してください。

## トラブルシューティング {#troubleshooting}

### 既存のメンバーはサインインできますが、新しいユーザーはできません {#existing-members-can-sign-in-but-new-users-cannot}

Okta およびカスタムプロバイダーの構成では、ログイン用メールドメインが検証済みであることを確認します。その後、ユーザーを招待するか、自動登録を有効にします。

### シングルサインオンで最初にログインするよう求められます {#single-sign-on-asks-you-to-log-in-first}

Tuist アカウントのメールアドレスが組織の検証済みログイン用メールドメインに含まれていないか、ドメインがまだ検証されていないため、Tuist はプロバイダー ID を自動的にリンクしません。<.localized_link href="/guides/integrations/authentication/sso#link-an-existing-account">既存の Tuist アカウントをリンク</.localized_link> で説明されているように、通常のサインイン方法でログインし、リンクを確認してください。
### Tuist がメールアドレスに対応する組織を見つけられません {#tuist-cannot-find-an-organization-for-an-email-address}

ユーザーが想定される従業員のメールアドレスを入力しており、そのドメインが検証済みのログイン用メールドメインと完全に一致していることを確認します。既存のメンバーは、現在の組織メンバーシップを通じて検出される場合もあります。

### ドメイン検証が保留のままです {#domain-verification-remains-pending}

TXT レコードの名前と値が Tuist に表示されている値と完全に一致していることを確認します。DNS の変更には反映に時間がかかることがあるため、レコードが公開された後に検証を再試行してください。

### プロバイダーを変更した後、サインインができなくなりました {#sign-in-stopped-after-changing-the-provider}

新しいプロバイダーの構成を確認し、ログイン用メールドメインを検証して、強制を有効にする前にログインフローをテストします。