ข้ามไปยังเนื้อหาหลัก
สำหรับเพื่อนใหม่ของเรา:

Logto คือทางเลือกแทน Auth0 ที่ออกแบบมาสำหรับแอปและผลิตภัณฑ์ SaaS ยุคใหม่ โดยมีทั้งบริการ Cloud และ Open-source เพื่อช่วยให้คุณเปิดตัวระบบการจัดการเอกลักษณ์และการเข้าถึง (IAM) ได้อย่างรวดเร็ว สนุกกับการยืนยันตัวตน (การยืนยันตัวตน), การอนุญาต (การอนุญาต), และการจัดการหลายผู้เช่า ครบจบในที่เดียว

เราแนะนำให้เริ่มต้นด้วย tenant สำหรับการพัฒนาแบบฟรีบน Logto Cloud เพื่อให้คุณสามารถสำรวจฟีเจอร์ทั้งหมดได้อย่างง่ายดาย

ในบทความนี้ เราจะพาคุณไปทีละขั้นตอนเพื่อสร้างประสบการณ์ลงชื่อเข้าใช้ Google (การยืนยันตัวตนของผู้ใช้) อย่างรวดเร็วด้วย iOS (Swift) และ Logto

ข้อกำหนดเบื้องต้น

  • มี Logto instance ที่พร้อมใช้งาน ดู หน้าแนะนำ เพื่อเริ่มต้นใช้งาน
  • มีความรู้พื้นฐานเกี่ยวกับ iOS (Swift)
  • มีบัญชี Google ที่ใช้งานได้

สร้างแอปพลิเคชันใน Logto​

Logto สร้างขึ้นบนพื้นฐานของการยืนยันตัวตน OpenID Connect (OIDC) และการอนุญาต OAuth 2.0 โดยรองรับการจัดการข้อมูลระบุตัวตนแบบรวมศูนย์ข้ามหลายแอปพลิเคชัน ซึ่งมักเรียกว่า การลงชื่อเข้าใช้ครั้งเดียว (Single Sign-On; SSO)

ในการสร้างแอปพลิเคชัน Native app ของคุณ เพียงทำตามขั้นตอนเหล่านี้:

  1. เปิด Logto Console ในส่วน "เริ่มต้นใช้งาน" ให้คลิกที่ลิงก์ "ดูทั้งหมด" เพื่อเปิดรายการเฟรมเวิร์กของแอปพลิเคชัน หรือคุณสามารถไปที่ Logto Console > Applications แล้วคลิกปุ่ม "สร้างแอปพลิเคชัน" Get started
  2. ในหน้าต่างที่เปิดขึ้น ให้คลิกที่ส่วน "Native app" หรือกรองเฟรมเวิร์ก "Native app" ทั้งหมดที่มีโดยใช้ช่องกรองด่วนทางซ้ายมือ จากนั้นคลิกที่การ์ดเฟรมเวิร์ก "iOS (Swift)" เพื่อเริ่มสร้างแอปพลิเคชันของคุณ Frameworks
  3. กรอกชื่อแอปพลิเคชัน เช่น "Bookstore" แล้วคลิก "สร้างแอปพลิเคชัน"

🎉 เยี่ยมมาก! คุณเพิ่งสร้างแอปพลิเคชันแรกของคุณใน Logto คุณจะเห็นหน้าข้อความแสดงความยินดีซึ่งมีคู่มือการเชื่อมต่ออย่างละเอียด ให้ทำตามคู่มือเพื่อดูประสบการณ์ที่จะเกิดขึ้นในแอปพลิเคชันของคุณ

ผสานรวม iOS (Swift) กับ Logto​

เพิ่ม Logto SDK เป็น dependency​

บันทึก:

The minimum supported iOS version of Logto Swift SDK is iOS 13.

Logto Swift SDK comes in two major versions:

  • v1: Opens the sign-in experience in an embedded WebView, which is required by the native social plugin targets, but does not support passkey sign-in (WebView does not support WebAuthn, the underlying standard of passkeys).
  • v2 (beta): Opens the sign-in experience in ASWebAuthenticationSession (the system browser), which unlocks passkey sign-in and shares the browser session. Note that v2 removes the native social plugin targets; social connectors still work through the browser. If you depend on the native WeChat or Alipay SDK handoff, stay on v1.

This guide covers both versions. Choose your version in the tabs below, and the choice will be kept in sync throughout this guide.

Use the following URL to add Logto SDK as a dependency in Swift Package Manager.

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

Since Xcode 11, you can directly import a Swift package w/o any additional tool.

When Xcode asks for the package version, choose the version you want to integrate:

v2 is released as 2.0.0-beta.x prereleases until GA. Use 2.0.0-beta.1 or the latest 2.0.0-beta.x prerelease as the version. During beta, we recommend selecting the prerelease explicitly instead of relying on a normal version range to pick it automatically.

If you use Package.swift directly:

Package.swift
.package(url: "https://github.com/logto-io/swift.git", exact: "2.0.0-beta.1")

We do not support Carthage and CocoaPods at the time due to some technical issues.

Carthage​

Carthage needs a xcodeproj file to build. We will try to find a workaround later.

CocoaPods​

CocoaPods does not support local dependency and monorepo, thus it's hard to create a .podspec for this 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


Configure redirect URI​

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

Redirect URI ใน Logto Console

In v2, the sign-in experience opens in ASWebAuthenticationSession (the system browser), and the redirect is routed back to your app through OS-level callback matching. For a custom scheme redirect URI such as io.logto.app://callback, register only the scheme part (io.logto.app) in your app's Info.plist, then add the full redirect URI to your Logto application's Redirect URIs.

In Xcode, open your app target, select Info, expand URL Types, and add one entry with io.logto.app in URL Schemes. If you edit Info.plist directly, add:

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>

For the browser flow in v2, you do not need to call LogtoClient.handle(url:); that plugin handoff API was removed with the embedded WebView flow.

You can also use an HTTPS redirect URI such as https://example.com/callback:

  1. Add the Associated Domains capability to your app.
  2. Configure webcredentials:example.com so ASWebAuthenticationSession can match HTTPS callbacks on iOS 17.4 and newer.
  3. If the same URL should also open your app as a Universal Link outside the authentication session, configure applinks:example.com and host a valid apple-app-site-association file for the domain and path.
  4. Add the HTTPS URI to your Logto application's Redirect URIs.
  5. Pass the same URI to signInWithBrowser.

On iOS 17.4 and newer, the SDK uses ASWebAuthenticationSession's HTTPS callback matching API so HTTPS redirects can automatically complete and dismiss the session. On older iOS versions, the authorization request can still use the HTTPS redirect URI, but the session may not close automatically unless your app handles the Universal Link callback itself. Keep a custom scheme redirect as a compatibility option if you need automatic completion on older iOS versions.

Sign-in and sign-out​

บันทึก:

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

In v2, client.signOut(postLogoutRedirectUri:) performs a complete sign-out: it clears the local credentials, revokes the refresh token, and ends the Logto session by opening the end session endpoint in the system browser. The browser then navigates back to your app through the post sign-out redirect URI. Before using it, switch to the application details page of Logto Console, add the post sign-out redirect URI io.logto.app://signed-out and click "Save changes". The post sign-out redirect URI can use the same custom scheme you registered for sign-in.

For example, in a SwiftUI app:

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 {
              // error occurred during sign in
            } catch {
              // other errors
            }
          }
        }
      }
    }
  }
}
บันทึก:
  • You can also call client.signOut() without a post sign-out redirect URI. No Console configuration is needed in this case: the browser shows the Logto sign-out page, and the user returns to the app by dismissing it manually.
  • If no UI context is available, you can call client.clearCredentials() to clear the local credentials and revoke the refresh token. Note that this keeps the Logto session in the browser, so the next signInWithBrowser may silently sign the user back in through that session.

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

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

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

เพิ่มตัวเชื่อมต่อ Google​

เพื่อเปิดใช้งานการลงชื่อเข้าใช้อย่างรวดเร็วและเพิ่มอัตราการเปลี่ยนผู้ใช้ ให้เชื่อมต่อกับ iOS (Swift) ในฐานะผู้ให้บริการข้อมูลระบุตัวตน (Identity provider) ตัวเชื่อมต่อโซเชียลของ Logto ช่วยให้คุณสร้างการเชื่อมต่อนี้ได้ภายในไม่กี่นาที โดยสามารถกรอกพารามิเตอร์ได้หลายค่า

ในการเพิ่มตัวเชื่อมต่อโซเชียล ให้ทำตามขั้นตอนดังนี้:

  1. ไปที่ Console > Connectors > Social Connectors
  2. คลิก "Add social connector" และเลือก "Google"
  3. ทำตามคู่มือ README กรอกข้อมูลที่จำเป็น และปรับแต่งการตั้งค่า
Connector tab
บันทึก:

หากคุณกำลังทำตามคู่มือ Connector แบบ in-place คุณสามารถข้ามส่วนถัดไปได้

ตั้งค่า Google OAuth app​

ขั้นตอนที่ 1: สร้างโปรเจกต์บน Google Auth Platform​

ก่อนที่คุณจะใช้ Google เป็นผู้ให้บริการการยืนยันตัวตน คุณต้องตั้งค่าโปรเจกต์ใน Google Cloud Console เพื่อขอรับข้อมูลประจำตัว OAuth 2.0 หากคุณมีโปรเจกต์อยู่แล้ว สามารถข้ามขั้นตอนนี้ได้

  1. ไปที่ Google Cloud Console และลงชื่อเข้าใช้ด้วยบัญชี Google ของคุณ
  2. คลิกปุ่ม Select a project ที่แถบเมนูด้านบน จากนั้นคลิกปุ่ม New Project เพื่อสร้างโปรเจกต์ใหม่
  3. ในโปรเจกต์ที่สร้างขึ้นใหม่ ไปที่ APIs & Services > OAuth consent screen เพื่อกำหนดค่าของแอป:
    • ข้อมูลแอป (App information): กรอก Application name และ Support email ที่จะแสดงบนหน้าขอความยินยอม
    • ผู้รับ (Audience): เลือกประเภทผู้รับที่คุณต้องการ:
      • Internal - สำหรับผู้ใช้ Google Workspace ภายในองค์กรของคุณเท่านั้น
      • External - สำหรับผู้ใช้ Google ทุกคน (ต้องผ่านการตรวจสอบเพื่อใช้งานจริง)
    • ข้อมูลติดต่อ (Contact information): ระบุอีเมลเพื่อให้ Google แจ้งเตือนคุณเกี่ยวกับการเปลี่ยนแปลงใด ๆ ของโปรเจกต์
    • ติ๊ก I agree to Google's policies เพื่อเสร็จสิ้นการตั้งค่าพื้นฐาน
  4. หากต้องการ ไปที่ส่วน Branding เพื่อแก้ไขข้อมูลผลิตภัณฑ์และอัปโหลด App logo ซึ่งจะแสดงบนหน้าขอความยินยอม OAuth เพื่อช่วยให้ผู้ใช้จดจำแอปของคุณ
เคล็ดลับ:

หากคุณเลือกประเภทผู้รับเป็น External คุณจะต้องเพิ่มผู้ใช้ทดสอบระหว่างการพัฒนา และเผยแพร่แอปของคุณสำหรับการใช้งานจริง

ขั้นตอนที่ 2: สร้างข้อมูลประจำตัว OAuth 2.0​

ไปที่หน้า Credentials ใน Google Cloud Console และสร้างข้อมูลประจำตัว OAuth สำหรับแอปพลิเคชันของคุณ

  1. คลิก Create Credentials > OAuth client ID
  2. เลือก Web application เป็นประเภทแอปพลิเคชัน
  3. กรอก Name ของ OAuth client เพื่อช่วยให้คุณระบุข้อมูลประจำตัวนี้ (ไม่ได้แสดงให้ผู้ใช้ปลายทางเห็น)
  4. กำหนดค่า URI ที่ได้รับอนุญาต:
    • Authorized JavaScript origins: เพิ่ม origin ของ Logto instance ของคุณ (เช่น https://your-logto-domain.com)
    • Authorized redirect URIs: เพิ่ม Callback URI ของ Logto (คัดลอกจาก Logto Google connector ของคุณ)
  5. คลิก Create เพื่อสร้าง OAuth client

ขั้นตอนที่ 3: กำหนดค่าตัวเชื่อมต่อ Logto ด้วยข้อมูลประจำตัว​

หลังจากสร้าง OAuth client แล้ว Google จะแสดงหน้าต่างพร้อมข้อมูลประจำตัวของคุณ:

  1. คัดลอก Client ID แล้ววางลงในช่อง clientId ใน Logto
  2. คัดลอก Client secret แล้ววางลงในช่อง clientSecret ใน Logto
  3. คลิก Save and Done ใน Logto เพื่อเชื่อมต่อระบบข้อมูลระบุตัวตนของคุณกับ Google
คำเตือน:

เก็บรักษา client secret ของคุณให้ปลอดภัย และอย่าเปิดเผยในโค้ดฝั่ง client หากถูกเปิดเผย ให้สร้างใหม่ทันที

ขั้นตอนที่ 4: กำหนดค่าขอบเขต (Scopes)​

ขอบเขต (Scopes) กำหนดสิทธิ์ที่แอปของคุณร้องขอจากผู้ใช้ และควบคุมว่าแอปของคุณสามารถเข้าถึงข้อมูลใดจากบัญชี Google ของผู้ใช้ได้บ้าง

กำหนดค่าขอบเขตใน Google Cloud Console​

  1. ไปที่ APIs & Services > OAuth consent screen > Scopes
  2. คลิก Add or Remove Scopes และเลือกเฉพาะขอบเขตที่แอปของคุณต้องการ:
    • การยืนยันตัวตน (Authentication) (จำเป็น):
      • https://www.googleapis.com/auth/userinfo.email
      • https://www.googleapis.com/auth/userinfo.profile
      • openid
    • การเข้าถึง API (API access) (ไม่บังคับ): เพิ่มขอบเขตเพิ่มเติมที่แอปของคุณต้องการ (เช่น Drive, Calendar, YouTube) ค้นหาบริการที่มีได้ใน Google API Library หากแอปของคุณต้องการเข้าถึง Google API เกินกว่าสิทธิ์พื้นฐาน ให้เปิดใช้งาน API เฉพาะที่แอปของคุณจะใช้ (เช่น Google Drive API, Gmail API, Calendar API) ใน Google API Library ก่อน
  3. คลิก Update เพื่อยืนยันการเลือก
  4. คลิก Save and Continue เพื่อบันทึกการเปลี่ยนแปลง

กำหนดค่าขอบเขตใน Logto​

เลือกวิธีใดวิธีหนึ่งหรือหลายวิธีต่อไปนี้ตามความต้องการของคุณ:

ตัวเลือกที่ 1: ไม่ต้องการขอบเขต API เพิ่มเติม

  • เว้นว่างช่อง Scopes ใน Logto Google connector ของคุณ
  • ขอบเขตเริ่มต้น openid profile email จะถูกขอโดยอัตโนมัติเพื่อให้ Logto สามารถดึงข้อมูลผู้ใช้พื้นฐานได้อย่างถูกต้อง

ตัวเลือกที่ 2: ขอขอบเขตเพิ่มเติมขณะลงชื่อเข้าใช้

  • กรอกขอบเขตทั้งหมดที่ต้องการในช่อง Scopes โดยคั่นด้วยช่องว่าง
  • ขอบเขตที่คุณระบุจะแทนที่ค่าเริ่มต้น ดังนั้นควรใส่ขอบเขตการยืนยันตัวตนเสมอ: https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile openid
  • ใช้ URL ขอบเขตแบบเต็ม ตัวอย่าง: https://www.googleapis.com/auth/calendar.readonly

ตัวเลือกที่ 3: ขอขอบเขตเพิ่มเติมภายหลัง

  • หลังจากผู้ใช้ลงชื่อเข้าใช้แล้ว คุณสามารถขอขอบเขตเพิ่มเติมตามต้องการโดยเริ่ม federated social authorization flow ใหม่ และอัปเดต token set ของผู้ใช้
  • ขอบเขตเพิ่มเติมเหล่านี้ไม่จำเป็นต้องกรอกในช่อง Scopes ของ Logto Google connector และสามารถทำได้ผ่าน Social Verification API ของ Logto

เมื่อทำตามขั้นตอนเหล่านี้ ตัวเชื่อมต่อ Logto Google ของคุณจะร้องขอเฉพาะสิทธิ์ที่แอปของคุณต้องการ — ไม่มากและไม่น้อยเกินไป

เคล็ดลับ:

หากแอปของคุณร้องขอขอบเขตเหล่านี้เพื่อเข้าถึง Google API และดำเนินการต่าง ๆ อย่าลืมเปิดใช้งาน Store tokens for persistent API access ใน Logto Google connector ดูรายละเอียดในหัวข้อถัดไป

ขั้นตอนที่ 5: ปรับแต่งการแจ้งเตือนการยืนยันตัวตน​

กำหนดค่า Prompts ใน Logto เพื่อควบคุมประสบการณ์การยืนยันตัวตนของผู้ใช้ Prompts คืออาร์เรย์ของสตริงที่ระบุประเภทของการโต้ตอบที่ต้องการจากผู้ใช้:

  • none - เซิร์ฟเวอร์การอนุญาตจะไม่แสดงหน้าการยืนยันตัวตนหรือขอความยินยอมใด ๆ หากผู้ใช้ยังไม่ได้รับการยืนยันตัวตนหรือยังไม่ได้ให้ความยินยอมสำหรับขอบเขตที่ร้องขอ จะส่งคืนข้อผิดพลาด ใช้เพื่อตรวจสอบการยืนยันตัวตนและ/หรือความยินยอมที่มีอยู่
  • consent - เซิร์ฟเวอร์การอนุญาตจะแจ้งให้ผู้ใช้ให้ความยินยอมก่อนส่งข้อมูลกลับไปยัง client จำเป็นสำหรับการเปิดใช้งาน offline access เพื่อเข้าถึง Google API
  • select_account - เซิร์ฟเวอร์การอนุญาตจะแจ้งให้ผู้ใช้เลือกบัญชีผู้ใช้ เหมาะสำหรับผู้ใช้ที่มีหลายบัญชี Google เพื่อเลือกบัญชีที่ต้องการใช้ในการยืนยันตัวตน

ขั้นตอนที่ 6: การตั้งค่าทั่วไป​

นี่คือการตั้งค่าทั่วไปบางประการที่แม้จะไม่ขัดขวางการเชื่อมต่อกับ Google แต่ก็อาจมีผลต่อประสบการณ์การยืนยันตัวตนของผู้ใช้ปลายทาง

ซิงค์ข้อมูลโปรไฟล์​

ในตัวเชื่อมต่อ Google คุณสามารถตั้งค่านโยบายการซิงค์ข้อมูลโปรไฟล์ เช่น ชื่อผู้ใช้และรูปประจำตัว เลือกได้ดังนี้:

  • ซิงค์เฉพาะตอนสมัคร (Only sync at sign-up): ดึงข้อมูลโปรไฟล์ครั้งเดียวเมื่อผู้ใช้ลงชื่อเข้าใช้ครั้งแรก
  • ซิงค์ทุกครั้งที่ลงชื่อเข้าใช้ (Always sync at sign-in): อัปเดตข้อมูลโปรไฟล์ทุกครั้งที่ผู้ใช้ลงชื่อเข้าใช้

เก็บโทเค็นเพื่อเข้าถึง Google APIs (ไม่บังคับ)​

หากคุณต้องการเข้าถึง Google APIs และดำเนินการต่าง ๆ ด้วยการอนุญาตจากผู้ใช้ (ไม่ว่าจะผ่าน social sign-in หรือ account linking) Logto จำเป็นต้องขอขอบเขต API ที่เกี่ยวข้องและเก็บโทเค็น

  1. เพิ่มขอบเขตที่ต้องการในการตั้งค่า OAuth consent screen ของ Google Cloud Console และ Logto Google connector
  2. เปิดใช้งาน Store tokens for persistent API access ใน Logto Google connector Logto จะเก็บ Google access และ refresh tokens อย่างปลอดภัยใน Secret Vault
  3. เพื่อให้แน่ใจว่า refresh tokens ถูกส่งกลับมา ให้ตั้งค่าตัวเชื่อมต่อ Logto Google ดังนี้:
    • ตั้งค่า Prompts ให้มี consent
    • เปิดใช้งาน Offline Access
คำเตือน:

คุณไม่จำเป็นต้องเพิ่ม offline_access ในช่อง Scope ของ Logto — การเพิ่มอาจทำให้เกิดข้อผิดพลาด Google จะใช้ access_type=offline โดยอัตโนมัติเมื่อเปิดใช้งาน offline access

ขั้นตอนที่ 7: เปิดใช้งาน Google One Tap (ไม่บังคับ)​

Google One Tap เป็นวิธีที่ปลอดภัยและสะดวกในการให้ผู้ใช้ลงชื่อเข้าใช้เว็บไซต์ของคุณด้วยบัญชี Google ผ่านอินเทอร์เฟซแบบ popup

เมื่อคุณตั้งค่าตัวเชื่อมต่อ Google แล้ว คุณจะเห็นการ์ดสำหรับ Google One Tap ในหน้ารายละเอียดตัวเชื่อมต่อ เปิดใช้งาน Google One Tap โดยสลับสวิตช์

ตัวเลือกการกำหนดค่า Google One Tap​

  • Auto-select credential if possible - ลงชื่อเข้าใช้ผู้ใช้โดยอัตโนติด้วยบัญชี Google หาก ตรงตามเงื่อนไขที่กำหนด
  • Cancel the prompt if user clicks/taps outside - ปิดหน้าต่าง Google One Tap หากผู้ใช้คลิกหรือตอบนอกหน้าต่าง หากปิดใช้งาน ผู้ใช้ต้องคลิกปุ่มปิดเพื่อปิดหน้าต่าง
  • Enable Upgraded One Tap UX on ITP browsers - เปิดใช้งานประสบการณ์ผู้ใช้ Google One Tap แบบใหม่บนเบราว์เซอร์ที่มี Intelligent Tracking Prevention (ITP) ดูข้อมูลเพิ่มเติมใน เอกสารนี้
คำเตือน:

อย่าลืมเพิ่มโดเมนของคุณในส่วน Authorized JavaScript origins ในการตั้งค่า OAuth client มิฉะนั้น Google One Tap จะไม่สามารถแสดงผลได้

ข้อจำกัดสำคัญของ Google One Tap​

หากคุณเปิดใช้งาน Store tokens for persistent API access พร้อมกับ Google One Tap คุณจะไม่ได้รับ access token หรือขอบเขตที่ร้องขอโดยอัตโนมัติ

การลงชื่อเข้าใช้ด้วย Google One Tap (ต่างจากปุ่ม "Sign in with Google" มาตรฐาน) จะ ไม่ ออก OAuth access token แต่จะคืนค่าเฉพาะ ID token (JWT ที่ลงลายเซ็น) เพื่อยืนยันตัวตนผู้ใช้เท่านั้น ไม่ได้ให้สิทธิ์เข้าถึง API

หากต้องการเข้าถึง Google APIs สำหรับผู้ใช้ที่ลงชื่อเข้าใช้ด้วย Google One Tap คุณสามารถใช้ Social Verification API ของ Logto เพื่อเริ่ม federated social authorization flow ใหม่หลังจากผู้ใช้ลงชื่อเข้าใช้ด้วย Google One Tap วิธีนี้ช่วยให้คุณร้องขอขอบเขตเพิ่มเติมตามต้องการและอัปเดต token set ของผู้ใช้ โดยไม่ต้องกรอกขอบเขตเหล่านั้นล่วงหน้าใน Logto Google connector วิธีนี้รองรับ incremental authorization ผู้ใช้จะถูกขอสิทธิ์เพิ่มเติมเฉพาะเมื่อแอปของคุณต้องการจริง ๆ

ศึกษาข้อมูลเพิ่มเติมเกี่ยวกับ ข้อจำกัดของ Google One Tap ในเอกสารทางการ

ขั้นตอนที่ 8: ทดสอบและเผยแพร่แอปของคุณ​

สำหรับแอป Internal​

หากประเภท Audience ใน Google ของคุณตั้งเป็น Internal แอปของคุณจะใช้ได้เฉพาะกับผู้ใช้ Google Workspace ภายในองค์กรของคุณ คุณสามารถทดสอบด้วยบัญชีใดก็ได้ในองค์กร

สำหรับแอป External​

หากประเภท Audience ของคุณเป็น External:

  1. ระหว่างการพัฒนา: ไปที่ OAuth consent screen > Test users และเพิ่มอีเมลผู้ใช้ทดสอบ เฉพาะผู้ใช้เหล่านี้เท่านั้นที่สามารถลงชื่อเข้าใช้แอปของคุณได้
  2. สำหรับการใช้งานจริง: คลิก Publish App ในส่วน OAuth consent screen เพื่อให้แอปของคุณพร้อมใช้งานสำหรับทุกคนที่มีบัญชี Google
บันทึก:

แอปที่ร้องขอขอบเขตที่ละเอียดอ่อนหรือถูกจำกัด อาจต้องผ่านการตรวจสอบโดย Google ก่อนเผยแพร่ ซึ่งอาจใช้เวลาหลายสัปดาห์

บันทึกการตั้งค่าของคุณ​

โปรดตรวจสอบให้แน่ใจว่าคุณได้กรอกค่าที่จำเป็นในพื้นที่การตั้งค่าตัวเชื่อมต่อ Logto เรียบร้อยแล้ว คลิก "บันทึกและเสร็จสิ้น" (หรือ "บันทึกการเปลี่ยนแปลง") และตัวเชื่อมต่อ Google ควรพร้อมใช้งานแล้ว

เปิดใช้งานตัวเชื่อมต่อ Google ในประสบการณ์การลงชื่อเข้าใช้​

เมื่อคุณสร้างตัวเชื่อมต่อโซเชียลสำเร็จแล้ว คุณสามารถเปิดใช้งานเป็นปุ่ม "ดำเนินการต่อด้วย Google" ในประสบการณ์การลงชื่อเข้าใช้ (Sign-in Experience) ได้

  1. ไปที่ Console > ประสบการณ์การลงชื่อเข้าใช้ > สมัครและลงชื่อเข้าใช้
  2. (ไม่บังคับ) เลือก "ไม่เกี่ยวข้อง" สำหรับตัวระบุการสมัคร หากคุณต้องการเฉพาะการเข้าสู่ระบบโซเชียล
  3. เพิ่มตัวเชื่อมต่อ Google ที่ตั้งค่าไว้แล้วในส่วน "เข้าสู่ระบบโซเชียล" (Social sign-in)
แท็บประสบการณ์การลงชื่อเข้าใช้ (Sign-in Experience tab)

การทดสอบและการตรวจสอบความถูกต้อง​

กลับไปที่แอป iOS (Swift) ของคุณ ตอนนี้คุณควรจะสามารถลงชื่อเข้าใช้ด้วย Google ได้แล้ว ขอให้สนุก!

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

กระบวนการสำหรับผู้ใช้ปลายทาง: Logto มีโฟลว์การยืนยันตัวตนสำเร็จรูปพร้อมใช้งาน รวมถึง MFA และ Enterprise SSO พร้อม API อันทรงพลังสำหรับการปรับแต่งการตั้งค่าบัญชี การตรวจสอบความปลอดภัย และประสบการณ์แบบหลายผู้เช่า (multi-tenant) ได้อย่างยืดหยุ่น

การอนุญาต (Authorization): การอนุญาต (Authorization) กำหนดว่าผู้ใช้สามารถทำอะไรหรือเข้าถึงทรัพยากรใดได้บ้างหลังจากได้รับการยืนยันตัวตนแล้ว สำรวจวิธีปกป้อง API ของคุณสำหรับแอปเนทีฟและแอปหน้าเดียว (SPA) และการใช้งานการควบคุมการเข้าถึงตามบทบาท (RBAC)

องค์กร (Organizations): ฟีเจอร์องค์กรมีประสิทธิภาพอย่างยิ่งใน SaaS แบบหลายผู้เช่าและแอป B2B โดยช่วยให้สร้างผู้เช่า จัดการสมาชิก RBAC ระดับองค์กร และ Just-in-Time Provisioning ได้

ชุดบทความ Customer IAM: บทความต่อเนื่องเกี่ยวกับการจัดการข้อมูลระบุตัวตนและการเข้าถึงของลูกค้า (Customer IAM) ตั้งแต่ระดับพื้นฐาน 101 ไปจนถึงหัวข้อขั้นสูงและอื่น ๆ