為你的 iOS (Swift) 應用程式新增驗證 (Authentication)
本指南假設你已在管理控制台中創建了一個類型為 "Native app" 的應用程式。
安裝
使用以下 URL 在 Swift Package Manager 中新增 Logto SDK 作為相依項目。
https://github.com/logto-io/swift.git
自 Xcode 11 起，你可以直接匯入 Swift package，無需任何額外工具。
由於一些技術問題，我們目前不支援 Carthage 和 CocoaPods。
Carthage
Carthage 需要一個 xcodeproj 檔案來建置，但由於我們使用原生社交插件的二進位目標，swift package generate-xcodeproj 會報錯。我們將嘗試尋找解決方案。
整合
初始化 LogtoClient
初始化客戶端時，透過 LogtoConfig 物件建立一個 LogtoClient 實例。
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 權杖 (ID Token) 和重新整理權杖 (Refresh Token) 等憑證儲存在 Keychain 中。因此，使用者返回時無需再次登入。
若要關閉此行為，將 usingPersistStorage 設為 false：
let config = try? LogtoConfig(
// ...
usingPersistStorage: false
)
實作登入與登出
在深入細節之前，以下是終端使用者體驗的快速概覽。登入流程可簡化如下：
- 你的應用程式呼叫登入方法。
- 使用者被重定向至 Logto 登入頁面。對於原生應用程式，系統瀏覽器會被開啟。
- 使用者登入後被重定向回你的應用程式（配置為重定向 URI）。
關於基於重導的登入
- 此驗證流程遵循 OpenID Connect (OIDC) 協議，Logto 強制執行嚴格的安全措施以保護使用者登入。
- 如果你有多個應用程式，可以使用相同的身分提供者 (IdP, Identity provider)（Logto）。一旦使用者登入其中一個應用程式，Logto 將在使用者訪問另一個應用程式時自動完成登入流程。
欲了解更多關於基於重導登入的原理和優勢，請參閱 Logto 登入體驗解析。
設定重定向 URI
讓我們切換到 Logto Console 的應用程式詳細資訊頁面。新增一個重定向 URI io.logto://callback，然後點擊「儲存變更」。
iOS SDK 中的重定向 URI 僅供內部使用。在連接器要求之前，不需要 添加 自訂 URL Scheme。
登入與登出
在呼叫 .signInWithBrowser(redirectUri:) 之前，請確保已在管理控制台中正確配置了 Redirect URI。
你可以使用 client.signInWithBrowser(redirectUri:) 來讓使用者登入，並使用 client.signOut() 來讓使用者登出。
例如，在 SwiftUI 應用程式中：
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 {
// 其他錯誤
}
}
}
}
}
}
}
檢查點：測試你的應用程式
現在，你可以測試你的應用程式：
- 執行你的應用程式，你會看到登入按鈕。
- 點擊登入按鈕，SDK 會初始化登入流程並將你重定向到 Logto 登入頁面。
- 登入後，你將被重定向回應用程式並看到登出按鈕。
- 點擊登出按鈕以清除權杖存儲並登出。
獲取使用者資訊
顯示使用者資訊
要顯示使用者資訊，你可以使用 client.getIdTokenClaims() 方法。例如，在 SwiftUI 應用程式中：
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")
}
}
}
}
請求額外的宣告 (Claims)
你可能會發現從 client.getIdTokenClaims() 返回的物件中缺少一些使用者資訊。這是因為 OAuth 2.0 和 OpenID Connect (OIDC) 的設計遵循最小權限原則 (PoLP, Principle of Least Privilege)，而 Logto 是基於這些標準構建的。
預設情況下，僅返回有限的宣告 (Claims)。如果你需要更多資訊，可以請求額外的權限範圍 (Scopes) 以存取更多宣告。
「宣告 (Claim)」是對主體所做的斷言；「權限範圍 (Scope)」是一組宣告。在目前的情況下，宣告是關於使用者的一部分資訊。
以下是權限範圍與宣告關係的非規範性範例：
「sub」宣告表示「主體 (Subject)」，即使用者的唯一識別符（例如使用者 ID）。
Logto SDK 將始終請求三個權限範圍：openid、profile 和 offline_access。
要請求額外的權限範圍 (Scopes)，你可以將權限範圍傳遞給 LogtoConfig 物件。例如：
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 權杖 (ID token) 膨脹，某些宣告 (Claims) 需要透過網路請求來獲取。例如，即使在權限範圍 (Scopes) 中請求了 custom_data 宣告，它也不會包含在使用者物件中。要存取這些宣告，你可以使用 client.fetchUserInfo() 方法：
let userInfo = try? client.fetchUserInfo()
// 現在你可以訪問宣告 `userInfo.custom_data`
權限範圍 (Scopes) 與宣告 (Claims)
Logto 使用 OIDC 權限範圍 (Scopes) 和宣告 (Claims) 慣例 來定義從 ID 權杖 (ID token) 和 OIDC 使用者資訊端點 (userinfo endpoint) 獲取使用者資訊的權限範圍和宣告。無論是「權限範圍 (Scope)」還是「宣告 (Claim)」，都是 OAuth 2.0 和 OpenID Connect (OIDC) 規範中的術語。
以下是支援的權限範圍 (Scopes) 及其對應的宣告 (Claims)：
openid
| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ |
|---|---|---|---|
| sub | string | 使用者的唯一識別符 | 否 |
profile
| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ |
|---|---|---|---|
| name | string | 使用者的全名 | 否 |
| username | string | 使用者的用戶名 | 否 |
| picture | string | 使用者個人資料圖片的 URL。此 URL 必須指向圖像文件（例如 PNG、JPEG 或 GIF 圖像文件），而不是包含圖像的網頁。請注意，此 URL 應特別參考適合在描述使用者時顯示的個人資料照片，而不是使用者拍攝的任意照片。 | 否 |
| created_at | number | 使用者創建的時間。時間以自 Unix epoch（1970-01-01T00:00:00Z）以來的毫秒數表示。 | 否 |
| updated_at | number | 使用者資訊最後更新的時間。時間以自 Unix epoch（1970-01-01T00:00:00Z）以來的毫秒數表示。 | 否 |
其他 標準宣告 包括 family_name、given_name、middle_name、nickname、preferred_username、profile、website、gender、birthdate、zoneinfo 和 locale 也將包含在 profile 權限範圍中，無需請求使用者資訊端點。與上述宣告的不同之處在於，這些宣告僅在其值不為空時返回，而上述宣告在值為空時將返回 null。
與標準宣告不同，created_at 和 updated_at 宣告使用毫秒而非秒。
email
| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ |
|---|---|---|---|
string | 使用者的電子郵件地址 | 否 | |
| email_verified | boolean | 電子郵件地址是否已驗證 | 否 |
phone
| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ |
|---|---|---|---|
| phone_number | string | 使用者的電話號碼 | 否 |
| phone_number_verified | boolean | 電話號碼是否已驗證 | 否 |
address
請參閱 OpenID Connect Core 1.0 以獲取地址宣告的詳細資訊。
custom_data
| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ |
|---|---|---|---|
| custom_data | object | 使用者的自訂資料 | 是 |
identities
| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ |
|---|---|---|---|
| identities | object | 使用者的連結身分 | 是 |
| sso_identities | array | 使用者的連結 SSO 身分 | 是 |
roles
| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ |
|---|---|---|---|
| roles | string[] | 使用者的角色 | 否 |
urn:logto:scope:organizations
| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ |
|---|---|---|---|
| organizations | string[] | 使用者所屬的組織 ID | 否 |
| organization_data | object[] | 使用者所屬的組織資料 | 是 |
urn:logto:scope:organization_roles
| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ |
|---|---|---|---|
| organization_roles | string[] | 使用者所屬的組織角色，格式為 <organization_id>:<role_name> | 否 |
考慮到效能和資料大小，如果「需要使用者資訊嗎？」為「是」，則表示該宣告不會顯示在 ID 權杖中，而會在 使用者資訊端點 回應中返回。
API 資源
我們建議先閱讀 🔐 角色型存取控制 (RBAC, Role-Based Access Control)，以瞭解 Logto RBAC 的基本概念以及如何正確設定 API 資源。
配置 Logto 用戶端
一旦你設定了 API 資源，就可以在應用程式中配置 Logto 時新增它們：
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 資源 (API resources)
)
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 時新增它們：
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 的資源標示符 (Resource Indicators) 指定請求的最終權限範圍將是所有目標服務中所有權限範圍的笛卡兒積。
因此，在上述情況中，權限範圍可以從 Logto 的定義中簡化，兩個 API 資源都可以擁有 read 和 write 權限範圍而不需要前綴。然後，在 Logto 配置中：
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 資源取得存取權杖 (Access token)
要獲取特定 API 資源的存取權杖 (Access token)，你可以使用 getAccessToken 方法：
let accessToken = try await client.getAccessToken(for: "https://shopping.your-app.com/api")
此方法將返回一個 JWT 存取權杖 (Access token)，當使用者擁有相關權限時，可以用來存取 API 資源。如果當前快取的存取權杖 (Access token) 已過期，此方法將自動嘗試使用重新整理權杖 (Refresh token) 獲取新的存取權杖 (Access token)。
將存取權杖附加到請求標頭
將權杖放在 HTTP 標頭的 Authorization 欄位中，使用 Bearer 格式（Bearer YOUR_TOKEN），即可完成。
Bearer 權杖的整合流程可能會根據你使用的框架或請求者而有所不同。選擇適合你的方式來應用請求的 Authorization 標頭。
await LogtoRequest.get(
useSession: session,
endpoint: userInfoEndpoint,
headers: ["Authorization": "Bearer \(accessToken)"]
)