ข้ามไปยังเนื้อหาหลัก

เพิ่มการยืนยันตัวตนให้กับแอป iOS (Swift) ของคุณ

บันทึก:

คู่มือนี้ถือว่าคุณได้สร้างแอปพลิเคชันประเภท "Native app" ใน Admin Console แล้ว

การติดตั้ง​

บันทึก:

เวอร์ชัน iOS ขั้นต่ำที่รองรับของ Logto Swift SDK คือ iOS 13

Logto Swift SDK มีสองเวอร์ชันหลัก:

  • v2: เปิดประสบการณ์การลงชื่อเข้าใช้ใน ASWebAuthenticationSession (เบราว์เซอร์ของระบบ) ซึ่งรองรับการลงชื่อเข้าใช้ด้วย passkey และแชร์เซสชันเบราว์เซอร์ โปรดทราบว่า v2 ได้ลบ native social plugin targets ออกแล้ว; ตัวเชื่อมต่อโซเชียล (social connectors) ยังคงทำงานผ่านเบราว์เซอร์ หากคุณต้องพึ่ง native WeChat หรือ Alipay SDK handoff ให้ใช้ v1 ต่อไป
  • v1: เปิดประสบการณ์การลงชื่อเข้าใช้ใน WebView ที่ฝังอยู่ ซึ่งจำเป็นสำหรับ native social plugin targets แต่ไม่รองรับ การลงชื่อเข้าใช้ด้วย passkey (WebView ไม่รองรับ WebAuthn ซึ่งเป็นมาตรฐานพื้นฐานของ passkey)

คู่มือนี้ครอบคลุมทั้งสองเวอร์ชัน เลือกเวอร์ชันของคุณในแท็บด้านล่าง และตัวเลือกจะถูกซิงค์ตลอดทั้งคู่มือนี้

ใช้ URL ต่อไปนี้เพื่อเพิ่ม Logto SDK เป็น dependency ใน Swift Package Manager

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

ตั้งแต่ Xcode 11 เป็นต้นมา คุณสามารถ นำเข้า Swift package ได้โดยตรง โดยไม่ต้องใช้เครื่องมือเพิ่มเติม

เมื่อ Xcode ถามหาเวอร์ชันของแพ็กเกจ ให้เลือกเวอร์ชันที่คุณต้องการใช้งาน:

ใช้เวอร์ชัน v2 ล่าสุดเป็นเวอร์ชันอ้างอิง เวอร์ชัน v2 ล่าสุดคือ 2.0.0

หากคุณใช้ Package.swift โดยตรง:

Package.swift
// เพิ่ม Logto SDK ด้วยเวอร์ชัน 2.0.0
.package(url: "https://github.com/logto-io/swift.git", from: "2.0.0")

ขณะนี้เรายังไม่รองรับ Carthage และ CocoaPods เนื่องจากปัญหาทางเทคนิคบางประการ

Carthage​

Carthage ต้องการไฟล์ xcodeproj เพื่อ build เราจะพยายามหาวิธีแก้ไขในภายหลัง

CocoaPods​

CocoaPods ไม่รองรับ local dependency และ monorepo ดังนั้นจึงยากที่จะสร้าง .podspec สำหรับ repo นี้

การเชื่อมต่อ​

เริ่มต้น LogtoClient​

เริ่มต้นไคลเอนต์โดยการสร้างอินสแตนซ์ LogtoClient ด้วยอ็อบเจกต์ LogtoConfig

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 (ID Token) และ โทเค็นรีเฟรช (Refresh Token) ไว้ใน Keychain ดังนั้นผู้ใช้ไม่จำเป็นต้องลงชื่อเข้าใช้อีกครั้งเมื่อกลับมา

หากต้องการปิดพฤติกรรมนี้ ให้ตั้งค่า usingPersistStorage เป็น false:

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

สร้างฟังก์ชันลงชื่อเข้าใช้และออกจากระบบ​

ก่อนที่เราจะลงลึกในรายละเอียด นี่คือภาพรวมประสบการณ์ของผู้ใช้ปลายทาง กระบวนการลงชื่อเข้าใช้สามารถสรุปได้ดังนี้:

  1. แอปของคุณเรียกใช้งานเมธอดลงชื่อเข้าใช้
  2. ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังหน้าลงชื่อเข้าใช้ของ Logto สำหรับแอปเนทีฟ ระบบจะเปิดเบราว์เซอร์ของระบบ
  3. ผู้ใช้ลงชื่อเข้าใช้และถูกเปลี่ยนเส้นทางกลับไปยังแอปของคุณ (ตามที่กำหนดไว้ใน redirect URI)

เกี่ยวกับการลงชื่อเข้าใช้แบบเปลี่ยนเส้นทาง (redirect-based sign-in)​

  1. กระบวนการยืนยันตัวตนนี้เป็นไปตามโปรโตคอล OpenID Connect (OIDC) และ Logto บังคับใช้มาตรการรักษาความปลอดภัยอย่างเข้มงวดเพื่อปกป้องการลงชื่อเข้าใช้ของผู้ใช้
  2. หากคุณมีหลายแอป คุณสามารถใช้ผู้ให้บริการข้อมูลระบุตัวตน (Logto) เดียวกันได้ เมื่อผู้ใช้ลงชื่อเข้าใช้แอปหนึ่งแล้ว Logto จะดำเนินการลงชื่อเข้าใช้โดยอัตโนมัติเมื่อผู้ใช้เข้าถึงแอปอื่น

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับเหตุผลและประโยชน์ของการลงชื่อเข้าใช้แบบเปลี่ยนเส้นทาง โปรดดูที่ อธิบายประสบการณ์การลงชื่อเข้าใช้ของ Logto


กำหนดค่า redirect URI​

ไปที่หน้ารายละเอียดแอปพลิเคชันของ Logto Console เพิ่ม Redirect URI io.logto.app://callback แล้วคลิก "บันทึกการเปลี่ยนแปลง" (Save changes)

Redirect URI ใน Logto Console

ใน v2 ประสบการณ์การลงชื่อเข้าใช้จะเปิดใน ASWebAuthenticationSession (เบราว์เซอร์ของระบบ) และการเปลี่ยนเส้นทาง (redirect) จะถูกส่งกลับไปยังแอปของคุณผ่านการจับคู่ callback ในระดับ OS สำหรับ redirect URI แบบ custom scheme เช่น io.logto.app://callback ให้ลงทะเบียนเฉพาะส่วน scheme (io.logto.app) ใน Info.plist ของแอปคุณ แล้วเพิ่ม redirect URI แบบเต็มไปยัง Redirect URIs ของแอป Logto ของคุณ

ใน Xcode ให้เปิด target ของแอปคุณ เลือก Info ขยาย URL Types และเพิ่มรายการหนึ่งโดยใส่ io.logto.app ใน URL Schemes หากคุณแก้ไข 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>

สำหรับ browser flow ใน v2 คุณไม่จำเป็นต้องเรียก LogtoClient.handle(url:) อีกต่อไป; API สำหรับ handoff ของปลั๊กอินนั้นถูกลบออกไปพร้อมกับ flow แบบ embedded WebView แล้ว

คุณสามารถใช้ redirect URI แบบ HTTPS เช่น https://example.com/callback ได้เช่นกัน:

  1. เพิ่มความสามารถ Associated Domains ให้กับแอปของคุณ
  2. กำหนดค่า webcredentials:example.com เพื่อให้ ASWebAuthenticationSession สามารถจับคู่ callback แบบ HTTPS บน iOS 17.4 ขึ้นไป
  3. หาก URL เดียวกันควรเปิดแอปของคุณเป็น Universal Link นอก session การยืนยันตัวตน ให้กำหนดค่า applinks:example.com และโฮสต์ไฟล์ apple-app-site-association ที่ถูกต้องสำหรับโดเมนและ path นั้น
  4. เพิ่ม URI แบบ HTTPS นี้ไปยัง Redirect URIs ของแอป Logto ของคุณ
  5. ส่ง URI เดียวกันนี้ไปที่ signInWithBrowser

บน iOS 17.4 ขึ้นไป SDK จะใช้ API การจับคู่ callback แบบ HTTPS ของ ASWebAuthenticationSession ทำให้ redirect แบบ HTTPS สามารถดำเนินการและปิด session ได้โดยอัตโนมัติ บน iOS เวอร์ชันเก่า คำขอการอนุญาตยังคงใช้ redirect URI แบบ HTTPS ได้ แต่ session อาจไม่ปิดเองโดยอัตโนมัติ เว้นแต่แอปของคุณจะจัดการ callback ของ Universal Link เอง ควรเก็บ redirect แบบ custom scheme ไว้เป็นตัวเลือกเพื่อความเข้ากันได้ หากคุณต้องการให้การดำเนินการเสร็จสมบูรณ์อัตโนมัติบน iOS เวอร์ชันเก่า

ลงชื่อเข้าใช้และออกจากระบบ​

บันทึก:

ก่อนเรียก .signInWithBrowser(redirectUri:) โปรดตรวจสอบให้แน่ใจว่าคุณได้กำหนดค่า Redirect URI ใน Admin Console อย่างถูกต้องแล้ว

ใน v2 client.signOut(postLogoutRedirectUri:) จะทำการออกจากระบบอย่างสมบูรณ์: ล้างข้อมูลรับรองในเครื่อง, เพิกถอนโทเค็นรีเฟรช (refresh token), และสิ้นสุด session ของ Logto โดยเปิด endpoint สำหรับจบ session ในเบราว์เซอร์ของระบบ จากนั้นเบราว์เซอร์จะนำทางกลับไปยังแอปของคุณผ่าน post sign-out redirect URI ก่อนใช้งาน ให้ไปที่หน้ารายละเอียดแอปใน Logto Console เพิ่ม post sign-out redirect URI io.logto.app://signed-out และคลิก "Save changes" post sign-out redirect URI สามารถใช้ custom scheme เดียวกับที่คุณลงทะเบียนสำหรับการลงชื่อเข้าใช้ได้

ตัวอย่างในแอป 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 {
              // ข้อผิดพลาดอื่น ๆ
            }
          }
        }
      }
    }
  }
}
บันทึก:
  • คุณสามารถเรียก client.signOut() โดยไม่ต้องระบุ post sign-out redirect URI ได้เช่นกัน กรณีนี้ไม่ต้องตั้งค่าใน Console: เบราว์เซอร์จะแสดงหน้าลงชื่อออกของ Logto และผู้ใช้จะกลับสู่แอปโดยปิดเบราว์เซอร์เอง
  • หากไม่มี context ของ UI คุณสามารถเรียก client.clearCredentials() เพื่อล้างข้อมูลรับรองในเครื่องและเพิกถอนโทเค็นรีเฟรช (refresh token) ได้ โปรดทราบว่าสิ่งนี้จะยังคง session ของ Logto ในเบราว์เซอร์อยู่ ดังนั้นการ signInWithBrowser ครั้งถัดไปอาจลงชื่อเข้าใช้ผู้ใช้อย่างเงียบ ๆ ผ่าน session เดิม

คง prompt "บันทึกรหัสผ่าน" ของ iOS ไว้​

ASWebAuthenticationSession จะปิดทันทีที่ Logto เปลี่ยนเส้นทางกลับไปยังแอปของคุณ ดังนั้น prompt "บันทึกรหัสผ่าน" ของ iOS จะถูกปิดหลังจากลงชื่อเข้าใช้ด้วยรหัสผ่าน หากต้องการคง prompt นี้ไว้ ให้ส่ง confirm_redirect_policy=password ใน extraParams Logto จะแสดงหน้าดำเนินการต่อหลังจากผู้ใช้กรอกรหัสผ่าน และจะกลับไปยังแอปของคุณเมื่อผู้ใช้กดดำเนินการต่อ:

try await client.signInWithBrowser(
  redirectUri: redirectUri,
  extraParams: ["confirm_redirect_policy": "password"]
)

ดูรายละเอียดเพิ่มเติมที่ Keep the iOS "Save Password" prompt

จุดตรวจสอบ: ทดสอบแอปพลิเคชันของคุณ​

ตอนนี้คุณสามารถทดสอบแอปพลิเคชันของคุณได้แล้ว:

  1. รันแอปพลิเคชันของคุณ คุณจะเห็นปุ่มลงชื่อเข้าใช้
  2. คลิกปุ่มลงชื่อเข้าใช้ SDK จะเริ่มกระบวนการลงชื่อเข้าใช้และเปลี่ยนเส้นทางคุณไปยังหน้าลงชื่อเข้าใช้ของ Logto
  3. หลังจากที่คุณลงชื่อเข้าใช้แล้ว คุณจะถูกเปลี่ยนเส้นทางกลับไปยังแอปพลิเคชันของคุณและเห็นปุ่มลงชื่อออก
  4. คลิกปุ่มลงชื่อออกเพื่อเคลียร์ที่เก็บโทเค็นและออกจากระบบ

รับข้อมูลผู้ใช้​

แสดงข้อมูลผู้ใช้​

หากต้องการแสดงข้อมูลของผู้ใช้ คุณสามารถใช้เมธอด client.getIdTokenClaims() ตัวอย่างเช่น ในแอป SwiftUI:

ContentView.swift
// ตัวอย่างโค้ด 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")
      }
    }
  }
}

ขอข้อมูลการอ้างสิทธิ์เพิ่มเติม​

คุณอาจพบว่าข้อมูลผู้ใช้บางอย่างหายไปในอ็อบเจกต์ที่ส่งคืนจาก client.getIdTokenClaims() สาเหตุเนื่องจาก OAuth 2.0 และ OpenID Connect (OIDC) ถูกออกแบบมาให้สอดคล้องกับหลักการสิทธิ์น้อยที่สุด (principle of least privilege; PoLP) และ Logto ถูกสร้างขึ้นบนมาตรฐานเหล่านี้

โดยปกติแล้ว จะมีการส่งคืนการอ้างสิทธิ์ (claim) แบบจำกัด หากคุณต้องการข้อมูลเพิ่มเติม คุณสามารถร้องขอขอบเขต (scope) เพิ่มเติมเพื่อเข้าถึงการอ้างสิทธิ์ (claim) ที่มากขึ้นได้

ข้อมูล:

"การอ้างสิทธิ์ (Claim)" คือการยืนยันข้อมูลบางอย่างเกี่ยวกับผู้ถูกอ้างถึง (subject); "ขอบเขต (Scope)" คือกลุ่มของการอ้างสิทธิ์ (claim) ในกรณีนี้ การอ้างสิทธิ์ (claim) คือข้อมูลบางอย่างเกี่ยวกับผู้ใช้

ตัวอย่างที่ไม่เป็นทางการของความสัมพันธ์ระหว่างขอบเขต (scope) กับการอ้างสิทธิ์ (claim) มีดังนี้:

เคล็ดลับ:

การอ้างสิทธิ์ (claim) "sub" หมายถึง "ผู้ถูกอ้างถึง (subject)" ซึ่งคือตัวระบุที่ไม่ซ้ำของผู้ใช้ (เช่น user ID)

Logto SDK จะร้องขอขอบเขต (scope) สามรายการเสมอ ได้แก่ openid, profile และ offline_access

หากต้องการขอขอบเขต (scopes) เพิ่มเติม คุณสามารถส่ง scopes ไปยังอ็อบเจกต์ 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,
  ]
)

จากนั้นคุณสามารถเข้าถึงการอ้างสิทธิ์ (claims) เพิ่มเติมในค่าที่คืนมาจาก client.getIdTokenClaims():

let claims = try? client.getIdTokenClaims()
// ตอนนี้คุณสามารถเข้าถึง claims เพิ่มเติม เช่น `claims?.email`, `claims?.phoneNumber` เป็นต้น

การอ้างสิทธิ์ (Claims) ที่ต้องใช้การร้องขอผ่านเครือข่าย​

เพื่อป้องกันไม่ให้โทเค็น ID (ID token) มีขนาดใหญ่เกินไป การอ้างสิทธิ์บางรายการจำเป็นต้องร้องขอผ่านเครือข่ายเพื่อดึงข้อมูล ตัวอย่างเช่น การอ้างสิทธิ์ custom_data จะไม่ถูกรวมอยู่ในอ็อบเจกต์ผู้ใช้ แม้ว่าจะร้องขอไว้ในขอบเขต (scopes) ก็ตาม หากต้องการเข้าถึงการอ้างสิทธิ์เหล่านี้ คุณสามารถใช้เมธอด client.fetchUserInfo():

let userInfo = try? await client.fetchUserInfo()
// ตอนนี้คุณสามารถเข้าถึง claim `userInfo?.customData`
เมธอดนี้จะดึงข้อมูลผู้ใช้โดยการร้องขอไปยัง จุดปลาย userinfo หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับขอบเขต (scopes) และการอ้างสิทธิ์ (claims) ที่มีอยู่ ดูที่หัวข้อ ขอบเขตและการอ้างสิทธิ์

ขอบเขตและการอ้างสิทธิ์​

Logto ใช้แนวทาง ขอบเขต (Scope) และ การอ้างสิทธิ์ (Claim) ของ OIDC เพื่อกำหนดขอบเขตและการอ้างสิทธิ์สำหรับดึงข้อมูลผู้ใช้จากโทเค็น ID (ID token) และ OIDC จุดปลาย userinfo ทั้ง "ขอบเขต (Scope)" และ "การอ้างสิทธิ์ (Claim)" เป็นคำศัพท์จากข้อกำหนดของ OAuth 2.0 และ OpenID Connect (OIDC)

สำหรับการอ้างสิทธิ์ OIDC มาตรฐาน การรวมอยู่ในโทเค็น ID จะถูกกำหนดอย่างเคร่งครัดโดยขอบเขตที่ร้องขอ การอ้างสิทธิ์เพิ่มเติม (เช่น custom_data และ organizations) สามารถตั้งค่าเพิ่มเติมให้ปรากฏในโทเค็น ID ได้ผ่าน การตั้งค่า Custom ID token

ต่อไปนี้คือรายการขอบเขต (Scopes) ที่รองรับและการอ้างสิทธิ์ (Claims) ที่เกี่ยวข้อง:

ขอบเขต OIDC มาตรฐาน​

openid (ค่าเริ่มต้น)

ชื่อการอ้างสิทธิ์ประเภทคำอธิบาย
substringตัวระบุที่ไม่ซ้ำของผู้ใช้

profile (ค่าเริ่มต้น)

ชื่อการอ้างสิทธิ์ประเภทคำอธิบาย
namestringชื่อเต็มของผู้ใช้
usernamestringชื่อผู้ใช้ของผู้ใช้
picturestringURL ของรูปโปรไฟล์ผู้ใช้ปลายทาง (End-User) URL นี้ต้องอ้างถึงไฟล์รูปภาพ (เช่น PNG, JPEG, หรือ GIF) ไม่ใช่หน้าเว็บที่มีรูปภาพ โปรดทราบว่า URL นี้ควรอ้างอิงถึงรูปโปรไฟล์ของผู้ใช้ปลายทางโดยเฉพาะ เหมาะสำหรับแสดงเมื่ออธิบายผู้ใช้ปลายทาง ไม่ใช่รูปภาพใด ๆ ที่ผู้ใช้ถ่ายมาโดยพลการ
created_atnumberเวลาที่สร้างผู้ใช้ปลายทาง เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z)
updated_atnumberเวลาที่ข้อมูลของผู้ใช้ปลายทางถูกอัปเดตล่าสุด เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z)

การอ้างสิทธิ์มาตรฐาน อื่น ๆ เช่น family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo, และ locale จะถูกรวมอยู่ในขอบเขต profile ด้วยโดยไม่จำเป็นต้องร้องขอ endpoint userinfo ความแตกต่างเมื่อเทียบกับการอ้างสิทธิ์ข้างต้นคือ การอ้างสิทธิ์เหล่านี้จะถูกส่งกลับเมื่อค่าของมันไม่ว่างเปล่าเท่านั้น ในขณะที่การอ้างสิทธิ์ข้างต้นจะคืนค่า null หากค่าว่างเปล่า

บันทึก:

ต่างจากการอ้างสิทธิ์มาตรฐาน การอ้างสิทธิ์ created_at และ updated_at ใช้หน่วยเป็นมิลลิวินาทีแทนที่จะเป็นวินาที

email

ชื่อการอ้างสิทธิ์ประเภทคำอธิบาย
emailstringอีเมลของผู้ใช้
email_verifiedbooleanอีเมลได้รับการยืนยันแล้วหรือไม่

phone

ชื่อการอ้างสิทธิ์ประเภทคำอธิบาย
phone_numberstringเบอร์โทรศัพท์ของผู้ใช้
phone_number_verifiedbooleanเบอร์โทรศัพท์ได้รับการยืนยันแล้วหรือไม่

address

โปรดดูรายละเอียดของการอ้างสิทธิ์ที่อยู่ได้ที่ OpenID Connect Core 1.0

ข้อมูล:

ขอบเขตที่มีเครื่องหมาย (ค่าเริ่มต้น) จะถูกร้องขอเสมอโดย Logto SDK การอ้างสิทธิ์ภายใต้ขอบเขต OIDC มาตรฐานจะถูกรวมอยู่ในโทเค็น ID เสมอเมื่อมีการร้องขอขอบเขตที่เกี่ยวข้อง — ไม่สามารถปิดได้

ขอบเขตเพิ่มเติม​

ขอบเขตต่อไปนี้เป็นขอบเขตที่ Logto ขยายขึ้นและจะคืนค่าการอ้างสิทธิ์ผ่าน userinfo endpoint การอ้างสิทธิ์เหล่านี้ยังสามารถตั้งค่าให้ถูกรวมอยู่ในโทเค็น ID ได้โดยตรงผ่าน Console > Custom JWT ดู Custom ID token สำหรับรายละเอียดเพิ่มเติม

custom_data

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายรวมในโทเค็น ID โดยค่าเริ่มต้น
custom_dataobjectข้อมูลกำหนดเองของผู้ใช้

identities

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายรวมในโทเค็น ID โดยค่าเริ่มต้น
identitiesobjectข้อมูลตัวตนที่เชื่อมโยงของผู้ใช้
sso_identitiesarrayข้อมูล SSO ที่เชื่อมโยงของผู้ใช้

roles

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายรวมในโทเค็น ID โดยค่าเริ่มต้น
rolesstring[]บทบาท (Role) ของผู้ใช้✅

urn:logto:scope:organizations

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายรวมในโทเค็น ID โดยค่าเริ่มต้น
organizationsstring[]รหัสองค์กรที่ผู้ใช้สังกัด✅
organization_dataobject[]ข้อมูลองค์กรที่ผู้ใช้สังกัด
บันทึก:

การอ้างสิทธิ์ขององค์กรเหล่านี้สามารถดึงได้ผ่าน userinfo endpoint เมื่อใช้ โทเค็นทึบ (Opaque token) อย่างไรก็ตาม โทเค็นทึบไม่สามารถใช้เป็นโทเค็นองค์กรสำหรับเข้าถึงทรัพยากรเฉพาะองค์กร ดู โทเค็นทึบและองค์กร สำหรับรายละเอียดเพิ่มเติม

urn:logto:scope:organization_roles

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายรวมในโทเค็น ID โดยค่าเริ่มต้น
organization_rolesstring[]บทบาทขององค์กรที่ผู้ใช้สังกัดในรูปแบบ <organization_id>:<role_name>✅

ทรัพยากร API​

เราแนะนำให้อ่าน 🔐 การควบคุมการเข้าถึงตามบทบาท (RBAC) ก่อน เพื่อทำความเข้าใจแนวคิดพื้นฐานของ RBAC ใน Logto และวิธีตั้งค่าทรัพยากร API อย่างถูกต้อง

กำหนดค่าไคลเอนต์ Logto​

เมื่อคุณตั้งค่า ทรัพยากร API (API resources) เรียบร้อยแล้ว คุณสามารถเพิ่มทรัพยากรเหล่านี้ขณะกำหนดค่า 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 (API resources)
)
let client = LogtoClient(useConfig: config)

แต่ละ ทรัพยากร API (API resource) จะมี สิทธิ์ (scopes) ของตัวเอง

ตัวอย่างเช่น ทรัพยากร 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) ที่ร้องขอ
  scopes: ["shopping:read", "shopping:write", "store:read", "store:write"],
  // ทรัพยากร (resources) ที่ร้องขอ
  resources: ["https://shopping.your-app.com/api", "https://store.your-app.com/api"],
)
let client = LogtoClient(useConfig: config)

คุณอาจสังเกตได้ว่า ขอบเขต (scopes) ถูกกำหนดแยกจาก ทรัพยากร API (API resources) นี่เป็นเพราะ Resource Indicators for OAuth 2.0 ระบุว่า ขอบเขตสุดท้ายสำหรับคำขอจะเป็นผลคูณคาร์ทีเซียนของขอบเขตทั้งหมดในบริการเป้าหมายทั้งหมด

ดังนั้น ในกรณีข้างต้น ขอบเขต (scopes) สามารถทำให้เรียบง่ายขึ้นจากการกำหนดใน Logto โดยทั้งสอง ทรัพยากร API (API resources) สามารถมีขอบเขต 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"], // ทรัพยากร API ที่ร้องขอ
)
let client = LogtoClient(useConfig: config)

สำหรับแต่ละ ทรัพยากร API (API resource) จะร้องขอทั้งขอบเขต read และ write

บันทึก:

คุณสามารถร้องขอขอบเขต (scopes) ที่ไม่ได้กำหนดไว้ใน ทรัพยากร API (API resources) ได้ เช่น คุณสามารถร้องขอขอบเขต email ได้ แม้ว่า ทรัพยากร API (API resources) จะไม่มีขอบเขต email ให้ ขอบเขตที่ไม่มีจะถูกละเว้นอย่างปลอดภัย

หลังจากลงชื่อเข้าใช้สำเร็จ Logto จะออกขอบเขตที่เหมาะสมให้กับ ทรัพยากร API (API resources) ตามบทบาทของผู้ใช้

ดึงโทเค็นการเข้าถึง (Access token) สำหรับทรัพยากร API​

เพื่อดึงโทเค็นการเข้าถึง (Access token) สำหรับทรัพยากร API เฉพาะ คุณสามารถใช้เมธอด getAccessToken ได้ดังนี้:

ContentView.swift
let accessToken = try await client.getAccessToken(for: "https://shopping.your-app.com/api")
// ดึงโทเค็นการเข้าถึง (access token)

เมธอดนี้จะส่งคืนโทเค็นการเข้าถึง (JWT access token) ที่สามารถใช้เข้าถึงทรัพยากร API ได้เมื่อผู้ใช้มีสิทธิ์ที่เกี่ยวข้อง หากโทเค็นการเข้าถึงที่แคชไว้หมดอายุแล้ว เมธอดนี้จะพยายามใช้โทเค็นรีเฟรช (Refresh token) เพื่อขอโทเค็นการเข้าถึงใหม่โดยอัตโนมัติ

แนบโทเค็นการเข้าถึงกับ request headers​

ให้นำโทเค็นไปใส่ในฟิลด์ Authorization ของ HTTP headers ในรูปแบบ Bearer (Bearer YOUR_TOKEN) ก็พร้อมใช้งาน

บันทึก:

ขั้นตอนการเชื่อมต่อ Bearer Token อาจแตกต่างกันไปตาม framework หรือ requester ที่คุณใช้ เลือกวิธีที่เหมาะสมในการใส่ request header Authorization

let userInfo: LogtoCore.UserInfoResponse = try await LogtoRequest.get(
  useSession: session,
  endpoint: userInfoEndpoint,
  headers: ["Authorization": "Bearer \(accessToken)"]
)

อ่านเพิ่มเติม​

กระบวนการสำหรับผู้ใช้ปลายทาง: กระบวนการยืนยันตัวตน, กระบวนการบัญชี, และกระบวนการองค์กร ตั้งค่าตัวเชื่อมต่อ การอนุญาต (Authorization)