メインコンテンツまでスキップ
新しい友達のために:

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

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

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

前提条件

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

Logto でアプリケーションを作成する

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

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

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

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

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")

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 に保存します。したがって、ユーザーは戻ってきたときに再度サインインする必要はありません。

この動作をオフにするには、usingPersistStoragefalse に設定します:

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

サインイン

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

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

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

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

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


リダイレクト URI の設定

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

Logto コンソールのリダイレクト URI

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

Xcode でアプリのターゲットを開き、Info を選択し、URL Types を展開して、URL Schemesio.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 フローとともに削除されました。

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

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

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

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

注記:

.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 でそのセッションを使ってサイレントサインインされる場合があります。

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

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

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

Google コネクターを追加する

迅速なサインインを有効にし、ユーザーコンバージョンを向上させるために、アイデンティティプロバイダー (IdP) として iOS (Swift) を接続します。Logto ソーシャルコネクターは、いくつかのパラメーター入力を許可することで、この接続を数分で確立するのに役立ちます。

ソーシャルコネクターを追加するには、次の手順に従ってください:

  1. Console > Connectors > Social Connectors に移動します。
  2. 「Add social connector」をクリックし、「Google」を選択します。
  3. README ガイドに従い、必要なフィールドを完了し、設定をカスタマイズします。
Connector tab
注記:

インプレースコネクターガイドに従っている場合は、次のセクションをスキップできます。

Google OAuth app を設定する

ステップ 1: Google Auth Platform でプロジェクトを作成する

Google を認証 (Authentication) プロバイダーとして利用する前に、Google Cloud Console でプロジェクトを作成し、OAuth 2.0 認証情報を取得する必要があります。すでにプロジェクトがある場合は、このステップをスキップできます。

  1. Google Cloud Console にアクセスし、Google アカウントでサインインします。
  2. 上部メニューバーの プロジェクトを選択 ボタンをクリックし、新しいプロジェクト ボタンをクリックしてプロジェクトを作成します。
  3. 作成したプロジェクトで、API とサービス > OAuth 同意画面 に移動し、アプリを設定します:
    • アプリ情報:同意画面に表示される アプリケーション名サポートメール を入力します
    • オーディエンス (Audience):希望するオーディエンスタイプを選択します:
      • 内部 - 組織内の Google Workspace ユーザーのみ
      • 外部 - すべての Google ユーザー向け(本番利用には検証が必要)
    • 連絡先情報:Google からプロジェクトの変更通知を受け取るためのメールアドレスを入力します
    • Google のポリシーに同意します にチェックを入れて基本設定を完了します
  4. 必要に応じて ブランディング セクションで製品情報を編集し、アプリロゴ をアップロードできます。OAuth 同意画面に表示され、ユーザーがアプリを認識しやすくなります。
ヒント:

外部 オーディエンスタイプを選択した場合、開発中はテストユーザーを追加し、本番利用時にはアプリを公開する必要があります。

ステップ 2: OAuth 2.0 認証情報を作成する

Google Cloud Console の 認証情報 ページに移動し、アプリケーション用の OAuth 認証情報を作成します。

  1. 認証情報を作成 > OAuth クライアント ID をクリックします。
  2. アプリケーションの種類として ウェブアプリケーション を選択します。
  3. OAuth クライアントの 名前 を入力します。これは認証情報の識別用で、エンドユーザーには表示されません。
  4. 許可済み URI を設定します:
    • 許可済み JavaScript オリジン:Logto インスタンスのオリジン(例:https://your-logto-domain.com)を追加します
    • 許可済みリダイレクト URI:Logto の Callback URI を追加します(Logto Google コネクターからコピー)
  5. 作成 をクリックして OAuth クライアントを生成します。

ステップ 3: Logto コネクターに認証情報を設定する

OAuth クライアント作成後、Google から認証情報が表示されます:

  1. クライアント ID をコピーし、Logto の clientId フィールドに貼り付けます
  2. クライアントシークレット をコピーし、Logto の clientSecret フィールドに貼り付けます
  3. Logto で 保存して完了 をクリックし、アイデンティティシステムと Google を接続します
警告:

クライアントシークレットは安全に保管し、クライアントサイドのコードで絶対に公開しないでください。漏洩した場合は直ちに新しいものを発行してください。

ステップ 4: スコープを設定する

スコープ (Scope) は、アプリがユーザーから要求する権限を定義し、Google アカウントからどのデータにアクセスできるかを制御します。

Google Cloud Console でスコープを設定する

  1. API とサービス > OAuth 同意画面 > スコープ に移動します。
  2. スコープを追加または削除 をクリックし、アプリに必要なスコープのみを選択します:
    • 認証 (Authentication)(必須)
      • https://www.googleapis.com/auth/userinfo.email
      • https://www.googleapis.com/auth/userinfo.profile
      • openid
    • API アクセス(任意):アプリに必要な追加スコープを追加します(例:Drive、Calendar、YouTube)。利用可能なサービスは Google API ライブラリ で確認できます。基本権限以外の Google API へアクセスする場合は、まず Google API ライブラリで該当 API(例:Google Drive API、Gmail API、Calendar API)を有効化してください。
  3. 更新 をクリックして選択を確定します。
  4. 保存して続行 をクリックして変更を適用します。

Logto でスコープを設定する

ニーズに応じて、以下のいずれかの方法を選択してください:

オプション 1: 追加の API スコープが不要な場合

  • Logto Google コネクターの Scopes フィールドは空欄のままにします。
  • デフォルトで openid profile email スコープがリクエストされ、Logto が基本的なユーザー情報を正しく取得できます。

オプション 2: サインイン時に追加スコープをリクエストする場合

  • 必要なすべてのスコープを Scopes フィールドにスペース区切りで入力します。
  • ここに記載したスコープがデフォルトを上書きするため、必ず認証 (Authentication) 用スコープ(https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile openid)を含めてください。
  • スコープはフル URL で記載します。例:https://www.googleapis.com/auth/calendar.readonly

オプション 3: 後からインクリメンタルにスコープをリクエストする場合

  • ユーザーがサインインした後、必要に応じてフェデレーテッドソーシャル認可 (Authorization) フローを再実行し、ユーザーのトークンセットを更新することで追加スコープをリクエストできます。
  • これらの追加スコープは Logto Google コネクターの Scopes フィールドに記載する必要はなく、Logto の Social Verification API を通じて実現できます。

これらの手順に従うことで、Logto Google コネクターはアプリに必要な権限だけをリクエストします。

ヒント:

アプリがこれらのスコープをリクエストして Google API へアクセス・操作する場合は、Logto Google コネクターで 永続的な API アクセス用にトークンを保存 を有効にしてください。詳細は次のセクションを参照してください。

ステップ 5: 認証 (Authentication) プロンプトをカスタマイズする

Logto で Prompts を設定し、ユーザー認証 (Authentication) 体験を制御できます。Prompts は、必要なユーザーインタラクションの種類を指定する文字列配列です:

  • none - 認可 (Authorization) サーバーは認証 (Authentication) や同意画面を表示しません。ユーザーがすでに認証 (Authentication) 済みかつ要求されたスコープに事前同意していない場合はエラーを返します。既存の認証 (Authentication) や同意の有無を確認する用途です。
  • consent - 認可 (Authorization) サーバーはクライアントに情報を返す前にユーザーに同意を求めます。Google API への オフラインアクセス を有効にするには必須です。
  • select_account - 認可 (Authorization) サーバーはユーザーにアカウント選択を促します。複数の Google アカウントを持つユーザーが認証 (Authentication) に使用するアカウントを選択できます。

ステップ 6: 一般設定

Google への接続自体には影響しませんが、エンドユーザーの認証 (Authentication) 体験に関わる一般的な設定です。

プロフィール情報の同期

Google コネクターでは、ユーザー名やアバターなどのプロフィール情報の同期ポリシーを設定できます。選択肢は以下の通りです:

  • サインアップ時のみ同期:ユーザーが初回サインインしたときにプロフィール情報を取得します。
  • サインイン時に常に同期:ユーザーがサインインするたびにプロフィール情報を更新します。

Google API へのトークン保存(任意)

Google API へアクセスし、ユーザーの認可 (Authorization) のもとで操作を行いたい場合(ソーシャルサインインやアカウント連携経由)、Logto は特定の API スコープを取得し、トークンを保存する必要があります。

  1. 必要なスコープを Google Cloud Console の OAuth 同意画面設定と Logto Google コネクターに追加します。
  2. Logto Google コネクターで 永続的な API アクセス用にトークンを保存 を有効にします。Logto は Google のアクセス トークン (Access token) およびリフレッシュ トークン (Refresh token) を Secret Vault に安全に保存します。
  3. リフレッシュ トークン (Refresh token) を確実に取得するため、Logto Google コネクターの設定を以下のようにします:
    • Promptsconsent を含める
    • オフラインアクセス を有効にする
警告:

Logto の Scope フィールドに offline_access を追加する必要はありません。追加するとエラーになる場合があります。Google ではオフラインアクセスが有効な場合、自動的に access_type=offline が使用されます。

ステップ 7: Google One Tap を有効にする(任意)

Google One Tap は、ユーザーが Google アカウントでポップアップインターフェースを使ってウェブサイトにサインインできる安全かつシームレスな方法です。

Google コネクターのセットアップが完了すると、コネクター詳細ページに Google One Tap 用のカードが表示されます。スイッチを切り替えて Google One Tap を有効にします。

Google One Tap の設定オプション

  • 条件を満たせば自動で認証情報を選択 - 特定条件 を満たす場合、Google アカウントで自動的にサインインします
  • ユーザーが外側をクリック/タップしたらプロンプトをキャンセル - ユーザーがプロンプト外をクリックまたはタップした場合、Google One Tap プロンプトを閉じます。無効の場合、ユーザーは閉じるボタンをクリックしてプロンプトを閉じる必要があります。
  • ITP ブラウザでアップグレードされた One Tap UX を有効化 - Intelligent Tracking Prevention (ITP) ブラウザでアップグレードされた Google One Tap ユーザー体験を有効にします。詳細は こちらのドキュメント を参照してください。
警告:

OAuth クライアント設定の 許可済み JavaScript オリジン セクションにドメインを追加してください。追加しないと Google One Tap は表示できません。

Google One Tap の重要な制限事項

永続的な API アクセス用にトークンを保存Google One Tap の両方を有効にしても、アクセス トークン (Access token) やリクエストしたスコープは自動的には取得できません。

Google One Tap サインイン(標準の「Google でサインイン」ボタンとは異なり)は、OAuth アクセス トークン (Access token) を発行しません。ID トークン (ID token)(署名付き JWT)だけが返され、ユーザーのアイデンティティは検証できますが、API アクセス権は付与されません。

Google One Tap ユーザーで Google API へアクセスするには、Logto の Social Verification API を使って、ユーザーが Google One Tap でサインインした後にフェデレーテッドソーシャル認可 (Authorization) フローを再実行してください。これにより、必要な追加スコープをリクエストし、ユーザーのトークンセットを更新できます。Logto Google コネクターのスコープ事前設定は不要です。この方法によりインクリメンタル認可 (Authorization) が可能となり、アプリが実際に必要とするタイミングでのみ追加権限の同意をユーザーに求められます。

Google One Tap の制限事項 については公式ドキュメントもご参照ください。

ステップ 8: アプリのテストと公開

内部アプリの場合

Google の オーディエンス (Audience) タイプが 内部 の場合、アプリは組織内の Google Workspace ユーザーのみ利用可能です。組織の任意のアカウントでテストできます。

外部アプリの場合

オーディエンス (Audience) タイプが 外部 の場合:

  1. 開発中OAuth 同意画面 > テストユーザー に移動し、テストユーザーのメールアドレスを追加します。これらのユーザーのみがアプリでサインインできます。
  2. 本番利用時:OAuth 同意画面セクションで アプリを公開 をクリックし、すべての Google アカウントユーザーが利用できるようにします。
注記:

センシティブまたは制限付きスコープを持つアプリは、公開前に Google の検証が必要な場合があります。このプロセスには数週間かかることがあります。

設定を保存する

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

サインイン体験で Google コネクターを有効にする

ソーシャルコネクターを正常に作成したら、サインイン体験で「Google で続行」ボタンとして有効にすることができます。

  1. Console > サインイン体験 > サインアップとサインイン に移動します。
  2. (オプション)ソーシャルログインのみが必要な場合は、サインアップ識別子に「該当なし」を選択します。
  3. 設定済みの Google コネクターを「ソーシャルサインイン」セクションに追加します。
サインイン体験タブ

テストと検証

iOS (Swift) アプリに戻ります。これで Google を使用してサインインできるはずです。お楽しみください!

さらなる読み物

エンドユーザーフロー:Logto は、MFA やエンタープライズシングルサインオン (SSO) を含む即時使用可能な認証 (Authentication) フローを提供し、アカウント設定、セキュリティ検証、マルチテナント体験の柔軟な実装のための強力な API を備えています。

認可 (Authorization):認可 (Authorization) は、ユーザーが認証 (Authentication) された後に行えるアクションやアクセスできるリソースを定義します。ネイティブおよびシングルページアプリケーションの API を保護し、ロールベースのアクセス制御 (RBAC) を実装する方法を探ります。

組織 (Organizations):特にマルチテナント SaaS や B2B アプリで効果的な組織機能は、テナントの作成、メンバー管理、組織レベルの RBAC、およびジャストインタイムプロビジョニングを可能にします。

顧客 IAM シリーズ:顧客(または消費者)アイデンティティとアクセス管理に関する連続ブログ投稿で、101 から高度なトピックまでを網羅しています。