How to build Microsoft Entra ID SAML enterprise SSO with iOS (Swift)

新しい友達のために:

Logto は、モダンなアプリや SaaS 製品向けに設計された Auth0 の代替です。 Cloud とオープンソースの両方のサービスを提供し、アイデンティティと管理 (IAM) システムを迅速に立ち上げるのに役立ちます。認証 (Authentication)、認可 (Authorization)、マルチテナント管理をすべて一つにまとめて楽しんでください。

Logto Cloud で無料の開発テナントから始めることをお勧めします。これにより、すべての機能を簡単に探索できます。

この記事では、iOS (Swift) と Logto を使用して、Microsoft Entra ID SAML enterprise SSO サインイン体験（ユーザー認証 (Authentication)）を迅速に構築する手順を説明します。

前提条件

稼働中の Logto インスタンス。紹介ページをチェックして始めてください。
iOS (Swift) の基本的な知識。
使用可能な Microsoft Entra ID SAML enterprise SSO アカウント。

Create an application in Logto

Logto は OpenID Connect (OIDC) 認証 (Authentication) と OAuth 2.0 認可 (Authorization) に基づいています。これは、複数のアプリケーション間でのフェデレーテッドアイデンティティ管理をサポートし、一般的にシングルサインオン (SSO) と呼ばれます。

あなたの Native app アプリケーションを作成するには、次の手順に従ってください：

Logto コンソールを開きます。「Get started」セクションで、「View all」リンクをクリックしてアプリケーションフレームワークのリストを開きます。あるいは、Logto Console > Applications に移動し、「Create application」ボタンをクリックします。
開いたモーダルで、左側のクイックフィルターチェックボックスを使用して、利用可能なすべての "Native app" フレームワークをフィルタリングするか、"Native app" セクションをクリックします。"iOS (Swift)" フレームワークカードをクリックして、アプリケーションの作成を開始します。
アプリケーション名を入力します。例：「Bookstore」と入力し、「Create application」をクリックします。

🎉 タダーン！Logto で最初のアプリケーションを作成しました。詳細な統合ガイドを含むお祝いページが表示されます。ガイドに従って、アプリケーションでの体験を確認してください。

Integrate iOS (Swift) SDK

Logto SDK を依存関係として追加する

注記:

Logto Swift SDK のサポートされている最小 iOS バージョンは iOS 13 です。

Logto Swift SDK には 2 つの主要バージョンがあります：

v2：サインイン体験を ASWebAuthenticationSession（システムブラウザ）で開きます。これによりパスキーサインインが可能になり、ブラウザセッションが共有されます。v2 ではネイティブソーシャルプラグインターゲットが削除されていますが、ソーシャルコネクターは引き続きブラウザ経由で動作します。ネイティブの WeChat や Alipay SDK 連携が必要な場合は v1 をご利用ください。
v1：サインイン体験を埋め込み WebView で開きます。これはネイティブソーシャルプラグインターゲットに必要ですが、パスキーサインインには対応していません（WebView はパスキーの基盤となる WebAuthn をサポートしていません）。

このガイドは両バージョンに対応しています。下記のタブでバージョンを選択してください。選択はガイド全体で同期されます。

Swift Package Manager で Logto SDK を依存関係として追加するには、以下の URL を使用してください。

https://github.com/logto-io/swift.git

Xcode 11 以降、Swift パッケージを直接インポートできます。追加ツールは不要です。

Xcode でパッケージバージョンを尋ねられたら、統合したいバージョンを選択してください：

バージョンには最新の v2 リリースを使用してください。最新の v2 バージョンは 2.0.0 です。

Package.swift を直接使用する場合：

Package.swift
// Logto Swift SDK を依存関係として追加
.package(url: "https://github.com/logto-io/swift.git", from: "2.0.0")

ネイティブソーシャルプラグインターゲットが必要な場合は、最新の v1 リリースを使用してください。最新の v1 バージョンは 1.2.0 です。

Package.swift を直接使用する場合：

Package.swift
// Logto Swift SDK を依存関係として追加
.package(url: "https://github.com/logto-io/swift.git", from: "1.2.0")

Carthage および CocoaPods には、技術的な理由により現時点では対応していません。

Carthage

Carthage はビルドに xcodeproj ファイルが必要です。今後回避策を検討します。

CocoaPods

CocoaPods はローカル依存関係およびモノレポに対応していないため、このリポジトリ用の .podspec を作成するのは困難です。

LogtoClient を初期化する

LogtoConfig オブジェクトを使用して LogtoClient インスタンスを作成することで、クライアントを初期化します。

ContentView.swift
import Logto
import LogtoClient

let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>", // 例: http://localhost:3001
  appId: "<your-app-id>"
)
let client = LogtoClient(useConfig: config)

備考:

デフォルトでは、ID トークンやリフレッシュトークンのような資格情報を Keychain に保存します。したがって、ユーザーは戻ってきたときに再度サインインする必要はありません。

この動作をオフにするには、usingPersistStorage を false に設定します：

let config = try? LogtoConfig(
  // ...
  usingPersistStorage: false
)

詳細に入る前に、エンドユーザー体験の概要を簡単にご紹介します。サインインプロセスは次のようにシンプルにまとめられます：

アプリがサインインメソッドを呼び出します。
ユーザーは Logto のサインインページにリダイレクトされます。ネイティブアプリの場合は、システムブラウザが開かれます。
ユーザーがサインインし、アプリ（リダイレクト URI として設定）に戻されます。

この認証 (Authentication) プロセスは OpenID Connect (OIDC) プロトコルに従い、Logto はユーザーのサインインを保護するために厳格なセキュリティ対策を講じています。
複数のアプリがある場合、同じアイデンティティプロバイダー (Logto) を使用できます。ユーザーがあるアプリにサインインすると、Logto は別のアプリにアクセスした際に自動的にサインインプロセスを完了します。

リダイレクトベースのサインインの理論と利点について詳しく知るには、Logto サインイン体験の説明を参照してください。

リダイレクト URI の設定

Logto コンソールのアプリケーション詳細ページに切り替えましょう。リダイレクト URI io.logto.app://callback を追加し、「変更を保存」をクリックします。

v2 では、サインイン体験は ASWebAuthenticationSession（システムブラウザ）で開かれ、リダイレクトは OS レベルのコールバックマッチングを通じてアプリに戻されます。io.logto.app://callback のようなカスタムスキームのリダイレクト URI を使う場合、アプリの Info.plist にはスキーム部分（io.logto.app）のみを登録し、Logto アプリケーションの Redirect URIs には完全なリダイレクト URI を追加してください。

Xcode でアプリのターゲットを開き、Info を選択し、URL Types を展開して、URL Schemes に io.logto.app を追加します。Info.plist を直接編集する場合は、以下を追加します：

Info.plist
<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleTypeRole</key>
    <string>Editor</string>
    <key>CFBundleURLName</key>
    <string>io.logto.app</string>
    <key>CFBundleURLSchemes</key>
    <array>
      <string>io.logto.app</string>
    </array>
  </dict>
</array>

v2 のブラウザフローでは、LogtoClient.handle(url:) を呼び出す必要はありません。このプラグインハンドオフ API は埋め込み WebView フローとともに削除されました。

カスタムスキームの代わりに Universal Links を使う？

https://example.com/callback のような HTTPS リダイレクト URI も利用できます：

アプリに Associated Domains 機能を追加します。
webcredentials:example.com を設定し、iOS 17.4 以降で ASWebAuthenticationSession が HTTPS コールバックをマッチできるようにします。
同じ URL で認証セッション外でも Universal Link としてアプリを開きたい場合は、applinks:example.com を設定し、ドメインとパスに有効な apple-app-site-association ファイルをホストします。
Logto アプリケーションの Redirect URIs に HTTPS URI を追加します。
signInWithBrowser に同じ URI を渡します。

iOS 17.4 以降では、SDK は ASWebAuthenticationSession の HTTPS コールバックマッチング API を利用するため、HTTPS リダイレクトで自動的にセッションを完了・終了できます。古い iOS バージョンでは、認可リクエストで HTTPS リダイレクト URI を使えますが、Universal Link コールバックをアプリ側で処理しない限りセッションが自動で閉じない場合があります。古い iOS バージョンで自動完了が必要な場合は、互換性のためにカスタムスキームリダイレクトも残しておいてください。

Logto コンソールのアプリケーション詳細ページに切り替えましょう。リダイレクト URI io.logto://callback を追加し、「変更を保存」をクリックします。

備考:

iOS SDK の Redirect URI は内部利用のみです。コネクターから要求されるまで Custom URL Scheme を追加する 必要はありません。

注記:

.signInWithBrowser(redirectUri:) を呼び出す前に、Admin Console でリダイレクト URI が正しく設定されていることを確認してください。 :::

v2 では、client.signOut(postLogoutRedirectUri:) を使うと完全なサインアウトが実行されます：ローカル認証情報のクリア、リフレッシュトークン (Refresh token) の取り消し、システムブラウザでエンドセッションエンドポイントを開いて Logto セッションを終了します。その後、ブラウザはサインアウト後リダイレクト URI を通じてアプリに戻ります。利用前に Logto Console のアプリケーション詳細ページでサインアウト後リダイレクト URI io.logto.app://signed-out を追加し、「Save changes」をクリックしてください。サインアウト後リダイレクト URI にはサインイン時に登録したカスタムスキームを使えます。

SwiftUI アプリの例：

ContentView.swift
// コメントは翻訳済み
struct ContentView: View {
  @State var isAuthenticated: Bool

  private let redirectUri = "io.logto.app://callback"
  private let postLogoutRedirectUri = "io.logto.app://signed-out"

  init() {
    isAuthenticated = client.isAuthenticated
  }

  var body: some View {
    VStack {
      if isAuthenticated {
        Button("Sign Out") {
          Task { [self] in
            let error = await client.signOut(postLogoutRedirectUri: postLogoutRedirectUri)
            if let error = error {
              print(error)
              return
            }
            isAuthenticated = false
          }
        }
      } else {
        Button("Sign In") {
          Task { [self] in
            do {
              try await client.signInWithBrowser(redirectUri: redirectUri)
              isAuthenticated = true
            } catch let error as LogtoClientErrors.SignIn {
              // サインイン中にエラーが発生
            } catch {
              // その他のエラー
            }
          }
        }
      }
    }
  }
}

注記:

サインアウト後リダイレクト URI なしで client.signOut() を呼ぶこともできます。この場合 Console 側の設定は不要です：ブラウザに Logto サインアウトページが表示され、ユーザーは手動で閉じてアプリに戻ります。
UI コンテキストが利用できない場合は、client.clearCredentials() でローカル認証情報のクリアとリフレッシュトークン (Refresh token) の取り消しが可能です。ただし、この場合ブラウザ上の Logto セッションは残るため、次回の signInWithBrowser でそのセッションを使ってサイレントサインインされる場合があります。

client.signInWithBrowser(redirectUri:) でユーザーのサインイン、client.signOut() でサインアウトができます。

SwiftUI アプリの例：

ContentView.swift
// コメントは翻訳済み
struct ContentView: View {
  @State var isAuthenticated: Bool

  init() {
    isAuthenticated = client.isAuthenticated
  }

  var body: some View {
    VStack {
      if isAuthenticated {
        Button("Sign Out") {
          Task { [self] in
            await client.signOut()
            isAuthenticated = false
          }
        }
      } else {
        Button("Sign In") {
          Task { [self] in
            do {
              try await client.signInWithBrowser(redirectUri: "io.logto://callback")
              isAuthenticated = true
            } catch let error as LogtoClientErrors.SignIn {
              // サインイン中にエラーが発生
            } catch {
              // その他のエラー
            }
          }
        }
      }
    }
  }
}

チェックポイント: アプリケーションをテストする

これで、アプリケーションをテストできます：

アプリケーションを実行すると、サインインボタンが表示されます。
サインインボタンをクリックすると、SDK がサインインプロセスを初期化し、Logto のサインインページにリダイレクトされます。
サインインすると、アプリケーションに戻り、サインアウトボタンが表示されます。
サインアウトボタンをクリックして、トークンストレージをクリアし、サインアウトします。

Add Microsoft Entra ID SAML enterprise SSO connector

アクセス管理を簡素化し、大規模なクライアント向けにエンタープライズレベルの保護を得るために、iOS (Swift) をフェデレーテッドアイデンティティプロバイダーとして接続します。Logto エンタープライズシングルサインオン (SSO) コネクターは、いくつかのパラメーター入力を許可することで、この接続を数分で確立するのに役立ちます。

エンタープライズ SSO コネクターを追加するには、次の手順に従ってください：

Logto コンソール > エンタープライズ SSO に移動します。

「エンタープライズコネクターを追加」ボタンをクリックし、SSO プロバイダーのタイプを選択します。Microsoft Entra ID (Azure AD)、Google Workspace、Okta の事前構築されたコネクターから選択するか、標準の OpenID Connect (OIDC) または SAML プロトコルを使用してカスタム SSO 接続を作成します。
一意の名前を指定します（例：Acme Company の SSO サインイン）。

「接続」タブで IdP と接続を構成します。各コネクタータイプのガイドを上記で確認してください。

「体験 (Experience)」タブで SSO 体験と企業の メールドメイン をカスタマイズします。SSO 対応のメールドメインでサインインするユーザーは、SSO 認証にリダイレクトされます。

変更を保存します。

Set up Azure AD SSO application

ステップ 1: Azure AD SSO アプリケーションの作成

Azure AD 側で SSO アプリケーションを作成することで、Azure AD SSO 統合を開始します。

Azure ポータルにアクセスし、管理者としてサインインします。
Microsoft Entra ID サービスを選択します。
サイドメニューを使用して Enterprise applications に移動します。New application をクリックし、Create your own application を選択します。

アプリケーション名を入力し、Integrate any other application you don't find in the gallery (Non-gallery) を選択します。
Setup single sign-on > SAML を選択します。

指示に従って、最初のステップとして、Logto によって提供される以下の情報を使用して基本的な SAML 設定を入力する必要があります。

Audience URI(SP Entity ID): これは、IdP への認証リクエスト中に SP の EntityId として機能し、Logto サービスのグローバルに一意の識別子として表されます。この識別子は、IdP と Logto 間で SAML アサーションやその他の認証関連データを安全に交換するために重要です。
ACS URL: Assertion Consumer Service (ACS) URL は、POST リクエストで SAML アサーションが送信される場所です。この URL は、IdP が SAML アサーションを Logto に送信するために使用されます。これは、Logto がユーザーのアイデンティティ情報を含む SAML 応答を受信し消費することを期待するコールバック URL として機能します。

Save をクリックして続行します。

ステップ 2: Logto で SAML SSO を構成する

SAML SSO 統合を機能させるには、IdP メタデータを Logto に戻す必要があります。Logto 側に戻り、Azure AD SSO コネクターの Connection タブに移動しましょう。

Logto は、IdP メタデータを構成するための 3 つの異なる方法を提供しています。最も簡単な方法は、Azure AD SSO アプリケーションの metadata URL を提供することです。

Azure AD SSO アプリケーションの SAML Certificates section から App Federation Metadata Url をコピーし、Logto の Metadata URL フィールドに貼り付けます。

Logto は URL からメタデータを取得し、SAML SSO 統合を自動的に構成します。

ステップ 3: ユーザー属性マッピングの設定

Logto は、IdP から返されるユーザー属性を Logto のユーザー属性にマッピングする柔軟な方法を提供します。Logto はデフォルトで次のユーザー属性を IdP から同期します：

id: ユーザーの一意の識別子。Logto は SAML レスポンスから nameID クレームを読み取り、ユーザーの SSO アイデンティティ ID として使用します。
email: ユーザーのメールアドレス。Logto はデフォルトで SAML レスポンスから email クレームを読み取り、ユーザーのプライマリメールとして使用します。
name: ユーザーの名前。

ユーザー属性のマッピングロジックは、Azure AD 側または Logto 側のいずれかで管理できます。

AzureAD ユーザー属性を Logto ユーザー属性に Logto 側でマッピングします。

Azure AD SSO アプリケーションの Attributes & Claims セクションにアクセスします。

次の属性名（名前空間プレフィックス付き）をコピーして、Logto の対応するフィールドに貼り付けます。
- http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
- http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name （推奨：この属性値マップを user.displayname に更新して、より良いユーザー体験を提供します）

AzureAD ユーザー属性を AzureAD 側で Logto ユーザー属性にマッピングします。

Azure AD SSO アプリケーションの Attributes & Claims セクションにアクセスします。

Edit をクリックし、Logto ユーザー属性設定に基づいて Additional claims フィールドを更新します：
- Logto ユーザー属性設定に基づいてクレーム名の値を更新します。
- 名前空間プレフィックスを削除します。
- Save をクリックして続行します。
次の設定で終了する必要があります：

Azure AD 側で追加のユーザー属性を指定することもできます。Logto は、ユーザーの sso_identity フィールドの下に IdP から返された元のユーザー属性の記録を保持します。

ステップ 4: Azure AD SSO アプリケーションにユーザーを割り当てる

Azure AD SSO アプリケーションの Users and groups セクションにアクセスします。Add user/group をクリックして、Azure AD SSO アプリケーションにユーザーを割り当てます。Azure AD SSO アプリケーションに割り当てられたユーザーのみが、Azure AD SSO コネクターを通じて認証 (Authentication) できます。

ステップ 5: メールドメインの設定と SSO コネクターの有効化

Logto のコネクター SSO 体験 タブで、あなたの組織の メールドメイン を提供してください。これにより、これらのユーザーに対する認証 (Authentication) 方法として SSO コネクターが有効になります。

指定されたドメインのメールアドレスを持つユーザーは、唯一の認証 (Authentication) 方法として SAML SSO コネクターを使用するようにリダイレクトされます。

Azure AD SSO 統合の詳細については、Azure AD の公式ドキュメントを確認してください。

オプション: 署名付き認証リクエスト (Authentication request) を強制する

Microsoft Entra ID では、署名付き SAML 認証リクエスト (Authentication request) を要求できます。Logto でこれを利用する場合、サインインの中断を避けるために次の順序で操作してください：

Logto コネクターの Connection タブで、Request signing certificate の下にある Generate new key をクリックし、アクティブキーの証明書をダウンロードします。
Entra ID アプリケーションのシングルサインオン設定で、証明書を Verification certificates の下にアップロードします。詳細は署名付き SAML 認証リクエスト (Authentication request) の強制を参照してください。
Logto に戻り、コネクターで Sign authentication request を有効にして保存します。
Entra ID で Require verification certificates をチェックし、サインインフローをテストします。

Entra ID は RSA-SHA256（Logto のデフォルトアルゴリズム）で署名されたリクエスト (Authentication request) のみを検証し、SP 発行のサインインリクエスト (Authentication request) に対してこの要件を強制します。セットアップ全体や証明書ローテーションの流れについては、SAML 認証リクエスト (Authentication request) に署名するを参照してください。

Save your configuration

Logto コネクター設定エリアで必要な値をすべて記入したことを確認してください。「保存して完了」または「変更を保存」をクリックすると、Microsoft Entra ID SAML enterprise SSO コネクターが利用可能になります。

エンタープライズコネクターを個別に設定する必要はありません。Logto は、ワンクリックでアプリケーションに SSO 統合を簡素化します。

移動先： Console > サインイン体験 > サインアップとサインイン。
「エンタープライズシングルサインオン (SSO)」トグルを有効にします。
変更を保存します。

有効にすると、サインインページに「シングルサインオン (SSO)」ボタンが表示されます。SSO が有効なメールドメインを持つエンタープライズユーザーは、エンタープライズアイデンティティプロバイダー (IdP) を使用してサービスにアクセスできます。

SP 主導の SSO や IdP 主導の SSO を含む SSO ユーザー体験について詳しくは、ユーザーフロー：エンタープライズ SSO を参照してください。

Testing and Validation

iOS (Swift) アプリに戻ります。これで Microsoft Entra ID SAML enterprise SSO を使用してサインインできるはずです。お楽しみください！

Create an application in Logto​

Integrate iOS (Swift) SDK​

Logto SDK を依存関係として追加する​

Carthage​

CocoaPods​

LogtoClient を初期化する​

サインイン​

リダイレクトベースのサインインについて​

リダイレクト URI の設定​

カスタムスキームの代わりに Universal Links を使う？​

サインインとサインアウト​

チェックポイント: アプリケーションをテストする​

Add Microsoft Entra ID SAML enterprise SSO connector​

Set up Azure AD SSO application​

ステップ 1: Azure AD SSO アプリケーションの作成​

ステップ 2: Logto で SAML SSO を構成する​

ステップ 3: ユーザー属性マッピングの設定​

ステップ 4: Azure AD SSO アプリケーションにユーザーを割り当てる​

ステップ 5: メールドメインの設定と SSO コネクターの有効化​

オプション: 署名付き認証リクエスト (Authentication request) を強制する​

Save your configuration​

Enable Microsoft Entra ID SAML enterprise SSO connector in Sign-in Experience​

Testing and Validation​

Further readings​