メインコンテンツまでスキップ

あなたの iOS (Swift) アプリケーションに認証 (Authentication) を追加する

注記:

このガイドは、Admin Console で「Native app」タイプのアプリケーションを作成したことを前提としています。

インストール​

次の URL を使用して、Swift Package Manager に Logto SDK を依存関係として追加します。

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

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

技術的な問題により、現在 Carthage と CocoaPods はサポートしていません。

Carthage​

Carthage は ビルドに xcodeproj ファイルを必要とします が、ネイティブソーシャルプラグインのバイナリターゲットを使用しているため、swift package generate-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
)

サインインとサインアウトを実装する​

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

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

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

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

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

リダイレクト URI の設定​

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

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

iOS SDK のリダイレクト URI は内部使用のみです。コネクターが要求するまで、カスタム URL スキーム を追加する必要は ありません。

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

注記:

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

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: "${
                props.redirectUris[0] ?? 'io.logto://callback'
              }")
              isAuthenticated = true
            } catch let error as LogtoClientErrors.SignIn {
              // サインイン中にエラーが発生しました
            } catch {
              // その他のエラー
            }
          }
        }
      }
    }
  }
}

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

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

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

ユーザー情報を取得する​

ユーザー情報を表示する​

ユーザーの情報を表示するには、client.getIdTokenClaims() メソッドを使用できます。例えば、SwiftUI アプリでは：

ContentView.swift
struct ContentView: View {
  @State var isAuthenticated: Bool
  @State var name: String?

  init() {
    isAuthenticated = client.isAuthenticated
    name = try? client.getIdTokenClaims().name
  }

  var body: some View {
    VStack {
      if isAuthenticated {
        Text("Welcome, \(name)")
      } else {
        Text("Please sign in")
      }
    }
  }
}

追加のクレームをリクエストする​

client.getIdTokenClaims() から返されるオブジェクトに一部のユーザー情報が欠けていることがあります。これは、OAuth 2.0 と OpenID Connect (OIDC) が最小特権の原則 (PoLP) に従うように設計されており、Logto はこれらの標準に基づいて構築されているためです。

デフォルトでは、限られたクレーム (Claims) が返されます。より多くの情報が必要な場合は、追加のスコープ (Scopes) をリクエストして、より多くのクレーム (Claims) にアクセスできます。

備考:

「クレーム (Claim)」はサブジェクトについての主張であり、「スコープ (Scope)」はクレーム (Claims) のグループです。現在のケースでは、クレーム (Claim) はユーザーに関する情報の一部です。

スコープ (Scope) とクレーム (Claim) の関係の非規範的な例を示します：

ヒント:

「sub」クレーム (Claim) は「サブジェクト (Subject)」を意味し、ユーザーの一意の識別子（つまり、ユーザー ID）です。

Logto SDK は常に 3 つのスコープ (Scopes) をリクエストします：openid、profile、および offline_access。

追加のスコープをリクエストするには、スコープを LogtoConfig オブジェクトに渡すことができます。例えば：

ContentView.swift
let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>", // 例: http://localhost:3001
  appId: "<your-app-id>",
  scopes: [
    UserScope.Email.rawValue,
    UserScope.Phone.rawValue,
  ]
)

その後、client.getIdTokenClaims() の戻り値で追加のクレームにアクセスできます：

let claims = try? client.getIdTokenClaims()
// これで追加のクレーム `claims.email`、`claims.phone` などにアクセスできます。

ネットワークリクエストが必要なクレーム (Claims)​

ID トークンの肥大化を防ぐために、一部のクレーム (Claims) は取得するためにネットワークリクエストが必要です。例えば、custom_data クレームはスコープで要求されてもユーザーオブジェクトに含まれません。これらのクレームにアクセスするには、 client.fetchUserInfo() メソッドを使用できます：

let userInfo = try? client.fetchUserInfo()
// これでクレーム `userInfo.custom_data` にアクセスできます。
このメソッドは、userinfo エンドポイントにリクエストを送信してユーザー情報を取得します。利用可能なスコープとクレームについて詳しくは、スコープとクレームのセクションを参照してください。

スコープとクレーム​

Logto は OIDC の スコープとクレームの規約 を使用して、ID トークンおよび OIDC userinfo エンドポイント からユーザー情報を取得するためのスコープとクレームを定義します。「スコープ」と「クレーム」は、OAuth 2.0 および OpenID Connect (OIDC) 仕様からの用語です。

こちらはサポートされているスコープと対応するクレーム (Claims) の一覧です：

openid

Claim nameType説明Needs userinfo?
substringユーザーの一意の識別子No

profile

Claim nameType説明Needs userinfo?
namestringユーザーのフルネームNo
usernamestringユーザーのユーザー名No
picturestringエンドユーザーのプロフィール画像の URL。この URL は画像ファイル（例：PNG、JPEG、GIF 画像ファイル）を指す必要があります。画像を含む Web ページではありません。この URL は、エンドユーザーを説明する際に表示するのに適したプロフィール写真を参照するべきであり、エンドユーザーが撮影した任意の写真ではありません。No
created_atnumberエンドユーザーが作成された時刻。時刻は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。No
updated_atnumberエンドユーザーの情報が最後に更新された時刻。時刻は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。No

その他の 標準クレーム (Standard Claims) には、family_name、given_name、middle_name、nickname、preferred_username、profile、website、gender、birthdate、zoneinfo、locale などがあり、これらも profile スコープに含まれ、userinfo エンドポイントをリクエストする必要はありません。上記のクレームとの違いは、これらのクレームは値が空でない場合のみ返される点です。一方、上記のクレームは値が空の場合 null が返されます。

注記:

標準クレームと異なり、created_at および updated_at クレームは秒ではなくミリ秒を使用しています。

email

Claim nameType説明Needs userinfo?
emailstringユーザーのメールアドレスNo
email_verifiedbooleanメールアドレスが認証済みかどうかNo

phone

Claim nameType説明Needs userinfo?
phone_numberstringユーザーの電話番号No
phone_number_verifiedboolean電話番号が認証済みかどうかNo

address

アドレスクレームの詳細については OpenID Connect Core 1.0 を参照してください。

custom_data

Claim nameType説明Needs userinfo?
custom_dataobjectユーザーのカスタムデータYes

identities

Claim nameType説明Needs userinfo?
identitiesobjectユーザーのリンク済みアイデンティティYes
sso_identitiesarrayユーザーのリンク済み SSO アイデンティティYes

roles

Claim nameType説明Needs userinfo?
rolesstring[]ユーザーのロール (Roles)No

urn:logto:scope:organizations

Claim nameType説明Needs userinfo?
organizationsstring[]ユーザーが所属する組織 (Organizations) の IDNo
organization_dataobject[]ユーザーが所属する組織 (Organizations) のデータYes
注記:

これらの組織 (Organizations) クレームは、不透明トークン (Opaque token) を使用する場合にも userinfo エンドポイント経由で取得できます。ただし、不透明トークン (Opaque token) は組織トークン (Organization token) として組織固有リソースへのアクセスには使用できません。詳細は 不透明トークン (Opaque token) と組織 (Organizations) を参照してください。

urn:logto:scope:organization_roles

Claim nameType説明Needs userinfo?
organization_rolesstring[]ユーザーが所属する組織 (Organizations) のロール (Roles)。形式は <organization_id>:<role_name>No

パフォーマンスとデータサイズを考慮し、「Needs userinfo?」が「Yes」の場合、そのクレーム (Claim) は ID トークン (ID token) には表示されず、userinfo エンドポイント のレスポンスで返されます。

API リソース​

まず 🔐 ロールベースのアクセス制御 (RBAC) を読むことをお勧めします。これにより、Logto の RBAC の基本概念と API リソースを適切に設定する方法を理解できます。

Logto クライアントを設定する​

API リソースを設定したら、アプリで Logto を設定する際にそれらを追加できます：

ContentView.swift
let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>", // 例: http://localhost:3001
  appId: "<your-app-id>",
  resources: ["https://shopping.your-app.com/api", "https://store.your-app.com/api"], // API リソースを追加
)
let client = LogtoClient(useConfig: config)

各 API リソースには独自の権限 (スコープ) があります。

例えば、https://shopping.your-app.com/api リソースには shopping:read と shopping:write の権限があり、https://store.your-app.com/api リソースには store:read と store:write の権限があります。

これらの権限を要求するには、アプリで Logto を設定する際にそれらを追加できます：

ContentView.swift
let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>",
  appId: "<your-app-id>",
  scopes: ["shopping:read", "shopping:write", "store:read", "store:write"],
  resources: ["https://shopping.your-app.com/api", "https://store.your-app.com/api"],
)
let client = LogtoClient(useConfig: config)

スコープが API リソースとは別に定義されていることに気付くかもしれません。これは、OAuth 2.0 のリソースインジケーター が、リクエストの最終的なスコープはすべてのターゲットサービスでのすべてのスコープの直積になると指定しているためです。

したがって、上記のケースでは、Logto での定義からスコープを簡略化できます。両方の API リソースは、プレフィックスなしで read と write スコープを持つことができます。その後、Logto の設定では：

ContentView.swift
let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>",
  appId: "<your-app-id>",
  scopes: ["read", "write"],
  resources: ["https://shopping.your-app.com/api", "https://store.your-app.com/api"],
)
let client = LogtoClient(useConfig: config)

各 API リソースは、read と write の両方のスコープを要求します。

注記:

API リソースで定義されていないスコープを要求しても問題ありません。例えば、API リソースに email スコープが利用できなくても、email スコープを要求できます。利用できないスコープは安全に無視されます。

サインインが成功すると、Logto はユーザーのロールに応じて適切なスコープを API リソースに発行します。

API リソースのアクセス トークンを取得する​

特定の API リソースのアクセス トークンを取得するには、getAccessToken メソッドを使用できます：

ContentView.swift
let accessToken = try await client.getAccessToken(for: "https://shopping.your-app.com/api")

このメソッドは、ユーザーが関連する権限を持っている場合に API リソースにアクセスするために使用できる JWT アクセス トークンを返します。現在キャッシュされているアクセス トークンが期限切れの場合、このメソッドは自動的にリフレッシュ トークンを使用して新しいアクセス トークンを取得しようとします。

アクセストークンをリクエストヘッダーに添付する​

トークンを HTTP ヘッダーの Authorization フィールドに Bearer 形式 (Bearer YOUR_TOKEN) で配置し、準備完了です。

注記:

Bearer トークンの統合フローは、使用しているフレームワークやリクエスターによって異なる場合があります。リクエスト Authorization ヘッダーを適用する独自の方法を選択してください。

await LogtoRequest.get(
  useSession: session,
  endpoint: userInfoEndpoint,
  headers: ["Authorization": "Bearer \(accessToken)"]
)

さらなる読み物​

エンドユーザーフロー：認証 (Authentication) フロー、アカウントフロー、組織フロー コネクターの設定 認可 (Authorization)