วิธีสร้างการลงชื่อเข้าใช้ด้วย OIDC ด้วย iOS (Swift)

สำหรับเพื่อนใหม่ของเรา:

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

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

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

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

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

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

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

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

เปิด Logto Console ในส่วน "เริ่มต้นใช้งาน" ให้คลิกที่ลิงก์ "ดูทั้งหมด" เพื่อเปิดรายการเฟรมเวิร์กของแอปพลิเคชัน หรือคุณสามารถไปที่ Logto Console > Applications แล้วคลิกปุ่ม "สร้างแอปพลิเคชัน"
ในหน้าต่างที่เปิดขึ้น ให้คลิกที่ส่วน "Native app" หรือกรองเฟรมเวิร์ก "Native app" ทั้งหมดที่มีโดยใช้ช่องกรองด่วนทางซ้ายมือ จากนั้นคลิกที่การ์ดเฟรมเวิร์ก "iOS (Swift)" เพื่อเริ่มสร้างแอปพลิเคชันของคุณ
กรอกชื่อแอปพลิเคชัน เช่น "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 (beta)
v1

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

Use the latest v1 release as the stable line. The latest v1 version is 1.2.0.

If you use Package.swift directly:

Package.swift
.package(url: "https://github.com/logto-io/swift.git", from: "1.2.0")

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
)

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

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

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

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

Configure redirect URI

v2 (beta)
v1

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

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.

Use Universal Links instead of a custom scheme?

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

Add the Associated Domains capability to your app.
Configure webcredentials:example.com so ASWebAuthenticationSession can match HTTPS callbacks on iOS 17.4 and newer.
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.
Add the HTTPS URI to your Logto application's Redirect URIs.
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.

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

ข้อมูล:

The Redirect URI in iOS SDK is only for internal use. There's NO NEED to add a Custom URL Scheme until a connector asks.

บันทึก:

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

v2 (beta)
v1

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.

You can use client.signInWithBrowser(redirectUri:) to sign in the user and client.signOut() to sign out the user.

For example, in a SwiftUI app:

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: "io.logto://callback")
              isAuthenticated = true
            } catch let error as LogtoClientErrors.SignIn {
              // error occurred during sign in
            } catch {
              // other errors
            }
          }
        }
      }
    }
  }
}

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

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

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

เพิ่มตัวเชื่อมต่อ OIDC

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

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

ไปที่ Console > Connectors > Social Connectors
คลิก "Add social connector" และเลือก "OIDC"
ทำตามคู่มือ README กรอกข้อมูลที่จำเป็น และปรับแต่งการตั้งค่า

บันทึก:

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

ตั้งค่า Standard OIDC app

สร้างแอป OIDC ของคุณ

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

กำหนดค่าตัวเชื่อมต่อของคุณ

เรารองรับเฉพาะประเภท grant แบบ "Authorization Code" เท่านั้นเพื่อเหตุผลด้านความปลอดภัย และเหมาะสมกับกรณีการใช้งานของ Logto อย่างสมบูรณ์

clientId และ clientSecret สามารถพบได้ในหน้ารายละเอียดแอป OIDC ของคุณ

clientId: client ID คือรหัสระบุที่ไม่ซ้ำกันซึ่งใช้ระบุแอปพลิเคชันลูกค้าในระหว่างการลงทะเบียนกับเซิร์ฟเวอร์อนุญาต รหัสนี้ใช้โดยเซิร์ฟเวอร์อนุญาตเพื่อตรวจสอบตัวตนของแอปพลิเคชันลูกค้าและเชื่อมโยงโทเค็นการเข้าถึงที่ได้รับอนุญาตกับแอปพลิเคชันลูกค้านั้นโดยเฉพาะ

clientSecret: client secret คือคีย์ลับที่ออกให้กับแอปพลิเคชันลูกค้าโดยเซิร์ฟเวอร์อนุญาตในระหว่างการลงทะเบียน แอปพลิเคชันลูกค้าจะใช้คีย์ลับนี้เพื่อยืนยันตัวเองกับเซิร์ฟเวอร์อนุญาตเมื่อขอโทเค็นการเข้าถึง client secret ถือเป็นข้อมูลลับและควรเก็บไว้อย่างปลอดภัยตลอดเวลา

tokenEndpointAuthMethod: วิธีการยืนยันตัวตนที่ token endpoint ใช้โดยแอปพลิเคชันลูกค้าเพื่อยืนยันตัวเองกับเซิร์ฟเวอร์อนุญาตเมื่อขอโทเค็นการเข้าถึง หากต้องการค้นหาวิธีที่รองรับ ให้ดูที่ฟิลด์ token_endpoint_auth_methods_supported ที่มีอยู่ใน discovery endpoint ของ OpenID Connect ของผู้ให้บริการ OAuth 2.0 หรือดูเอกสารที่เกี่ยวข้องของผู้ให้บริการ OAuth 2.0

clientSecretJwtSigningAlgorithm (ไม่บังคับ): ต้องระบุเฉพาะเมื่อ tokenEndpointAuthMethod เป็น client_secret_jwt อัลกอริทึมสำหรับเซ็นชื่อ JWT ด้วย client secret ใช้โดยแอปพลิเคชันลูกค้าเพื่อเซ็น JWT ที่ส่งไปยังเซิร์ฟเวอร์อนุญาตระหว่างการขอโทเค็น

scope: พารามิเตอร์ scope ใช้เพื่อระบุชุดทรัพยากรและสิทธิ์ที่แอปพลิเคชันลูกค้าต้องการเข้าถึง โดยปกติ scope จะถูกกำหนดเป็นรายการค่าที่คั่นด้วยช่องว่างซึ่งแสดงถึงสิทธิ์เฉพาะ ตัวอย่างเช่น ค่า scope เป็น "read write" อาจหมายถึงแอปพลิเคชันลูกค้าต้องการสิทธิ์อ่านและเขียนข้อมูลของผู้ใช้

คุณควรจะพบ authorizationEndpoint, tokenEndpoint, jwksUri และ issuer เป็นข้อมูลการตั้งค่าของ OpenID Provider ซึ่งควรมีอยู่ในเอกสารของผู้ให้บริการโซเชียล

authenticationEndpoint: endpoint นี้ใช้เพื่อเริ่มกระบวนการยืนยันตัวตน โดยปกติกระบวนการนี้จะเกี่ยวข้องกับการที่ผู้ใช้เข้าสู่ระบบและให้สิทธิ์แก่แอปพลิเคชันลูกค้าในการเข้าถึงทรัพยากรของตน

tokenEndpoint: endpoint นี้ใช้โดยแอปพลิเคชันลูกค้าเพื่อขอโทเค็น ID ที่สามารถใช้เข้าถึงทรัพยากรที่ร้องขอได้ โดยปกติแอปพลิเคชันลูกค้าจะส่งคำขอไปยัง token endpoint พร้อม grant type และ authorization code เพื่อรับโทเค็น ID

jwksUri: นี่คือ URL endpoint ที่สามารถดึง JSON Web Key Set (JWKS) ของผู้ให้บริการข้อมูลระบุตัวตนโซเชียล (IdP) ได้ JWKS คือชุดคีย์เข้ารหัสที่ IdP ใช้สำหรับเซ็นและตรวจสอบ JSON Web Token (JWT) ที่ออกระหว่างกระบวนการยืนยันตัวตน jwksUri ใช้โดย relying party (RP) เพื่อดึง public key ที่ IdP ใช้เซ็น JWT เพื่อให้ RP สามารถตรวจสอบความถูกต้องและความสมบูรณ์ของ JWT ที่ได้รับจาก IdP

issuer: นี่คือรหัสระบุที่ไม่ซ้ำกันของ IdP ที่ RP ใช้เพื่อตรวจสอบ JWT ที่ได้รับจาก IdP โดยจะถูกรวมอยู่ใน JWT เป็น iss claim (Id token เป็น JWT เสมอ) ค่า issuer ควรตรงกับ URL ของเซิร์ฟเวอร์อนุญาตของ IdP และควรเป็น URI ที่ RP เชื่อถือ เมื่อ RP ได้รับ JWT จะตรวจสอบ claim iss เพื่อให้แน่ใจว่าออกโดย IdP ที่เชื่อถือได้ และ JWT นั้นมีไว้สำหรับใช้งานกับ RP

jwksUri และ issuer ทำงานร่วมกันเพื่อให้กลไกที่ปลอดภัยสำหรับ RP ในการตรวจสอบตัวตนของผู้ใช้ปลายทางระหว่างกระบวนการยืนยันตัวตน โดยใช้ public key ที่ได้จาก jwksUri RP สามารถตรวจสอบความถูกต้องและความสมบูรณ์ของ JWT ที่ออกโดย IdP ค่า issuer ช่วยให้ RP ยอมรับเฉพาะ JWT ที่ออกโดย IdP ที่เชื่อถือได้ และ JWT เหล่านั้นมีไว้สำหรับใช้งานกับ RP

เนื่องจากต้องมี authentication request เสมอ จึงมี authRequestOptionalConfig สำหรับรวบรวมการตั้งค่าเพิ่มเติมทั้งหมด คุณสามารถดูรายละเอียดได้ที่ OIDC Authentication Request คุณอาจสังเกตว่าไม่มี nonce ใน config นี้ เนื่องจาก nonce ควรไม่ซ้ำกันในแต่ละ request เราจึงจัดการสร้าง nonce ในโค้ด ดังนั้นไม่ต้องกังวล! jwksUri และ issuer ที่กล่าวถึงก่อนหน้านี้ก็ถูกรวมอยู่ใน idTokenVerificationConfig เช่นกัน

คุณอาจสงสัยว่าทำไมโปรโตคอล OIDC มาตรฐานรองรับทั้ง implicit และ hybrid flows แต่ตัวเชื่อมต่อ Logto รองรับเฉพาะ authorization flow ได้มีการพิจารณาแล้วว่า implicit และ hybrid flows มีความปลอดภัยน้อยกว่า authorization flow ด้วยเหตุผลด้านความปลอดภัย Logto จึงรองรับเฉพาะ authorization flow เพื่อความปลอดภัยสูงสุดสำหรับผู้ใช้ แม้จะแลกกับความสะดวกเล็กน้อย

responseType และ grantType สามารถใช้ได้เฉพาะค่าคงที่กับ "Authorization Code" flow เท่านั้น เราจึงตั้งให้เป็นตัวเลือกและจะเติมค่าเริ่มต้นให้อัตโนมัติ

บันทึก:

สำหรับทุก flow type เรามีคีย์ customConfig (ไม่บังคับ) สำหรับใส่พารามิเตอร์ที่คุณต้องการปรับแต่ง ผู้ให้บริการข้อมูลระบุตัวตนโซเชียลแต่ละรายอาจมีการปรับแต่งโปรโตคอล OIDC มาตรฐานในแบบของตนเอง หากผู้ให้บริการที่คุณต้องการใช้ยึดตามมาตรฐาน OIDC อย่างเคร่งครัด คุณไม่จำเป็นต้องสนใจ customConfig

ประเภทของ config

ชื่อ	ประเภท	จำเป็นต้องระบุ
scope	string	ใช่
clientId	string	ใช่
clientSecret	string	ใช่
authorizationEndpoint	string	ใช่
tokenEndpoint	string	ใช่
idTokenVerificationConfig	IdTokenVerificationConfig	ใช่
authRequestOptionalConfig	AuthRequestOptionalConfig	ไม่จำเป็น
customConfig	Record<string, string>	ไม่จำเป็น

คุณสมบัติของ AuthRequestOptionalConfig	ประเภท	จำเป็นต้องระบุ
responseType	string	ไม่จำเป็น
tokenEndpoint	string	ไม่จำเป็น
responseMode	string	ไม่จำเป็น
display	string	ไม่จำเป็น
prompt	string	ไม่จำเป็น
maxAge	string	ไม่จำเป็น
uiLocales	string	ไม่จำเป็น
idTokenHint	string	ไม่จำเป็น
loginHint	string	ไม่จำเป็น
acrValues	string	ไม่จำเป็น

คุณสมบัติของ IdTokenVerificationConfig	ประเภท	จำเป็นต้องระบุ
jwksUri	string	ใช่
issuer	string \| string[]	ไม่จำเป็น
audience	string \| string[]	ไม่จำเป็น
algorithms	string[]	ไม่จำเป็น
clockTolerance	string \| number	ไม่จำเป็น
crit	Record<string, string \| boolean>	ไม่จำเป็น
currentDate	Date	ไม่จำเป็น
maxTokenAge	string \| number	ไม่จำเป็น
subject	string	ไม่จำเป็น
typ	string	ไม่จำเป็น

ดูรายละเอียดเพิ่มเติมเกี่ยวกับ IdTokenVerificationConfig ได้ที่ ที่นี่

การตั้งค่าทั่วไป

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

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

ชื่อผู้ให้บริการข้อมูลระบุตัวตน

ตัวเชื่อมต่อโซเชียลแต่ละตัวจะมีชื่อผู้ให้บริการข้อมูลระบุตัวตน (IdP) ที่ไม่ซ้ำกันเพื่อแยกแยะตัวตนของผู้ใช้ ตัวเชื่อมต่อทั่วไปจะใช้ชื่อ IdP แบบคงที่ แต่ตัวเชื่อมต่อแบบกำหนดเองต้องใช้ค่าที่ไม่ซ้ำกัน ดูข้อมูลเพิ่มเติมเกี่ยวกับ ชื่อ IdP

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

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

ซิงค์เฉพาะตอนสมัครสมาชิก: ดึงข้อมูลโปรไฟล์ครั้งเดียวเมื่อผู้ใช้ลงชื่อเข้าใช้ครั้งแรก
ซิงค์ทุกครั้งที่ลงชื่อเข้าใช้: อัปเดตข้อมูลโปรไฟล์ทุกครั้งที่ผู้ใช้ลงชื่อเข้าใช้

เก็บโทเค็นเพื่อเข้าถึง API ของบุคคลที่สาม (ไม่บังคับ)

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

เพิ่ม scope ที่ต้องการในช่อง scope ตามคำแนะนำข้างต้น
เปิดใช้งาน เก็บโทเค็นสำหรับการเข้าถึง API อย่างต่อเนื่อง ในตัวเชื่อมต่อ OIDC ของ Logto Logto จะเก็บ access token ไว้อย่างปลอดภัยใน Secret Vault
สำหรับผู้ให้บริการข้อมูลระบุตัวตน OAuth/OIDC มาตรฐาน ต้องรวม scope offline_access เพื่อรับ refresh token ป้องกันการขอความยินยอมจากผู้ใช้ซ้ำ

คำเตือน:

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

ใช้งานตัวเชื่อมต่อ OIDC

เมื่อคุณสร้างตัวเชื่อมต่อ OIDC และเชื่อมต่อกับผู้ให้บริการข้อมูลระบุตัวตนแล้ว คุณสามารถนำไปใช้ใน flow สำหรับผู้ใช้ปลายทาง เลือกตัวเลือกที่ตรงกับความต้องการของคุณ:

ใน Logto Console ไปที่ Sign-in & account > Sign-up and sign-in
เพิ่มตัวเชื่อมต่อ OIDC ในส่วน Social sign-in เพื่อให้ผู้ใช้ยืนยันตัวตนกับผู้ให้บริการข้อมูลระบุตัวตนของคุณ

ดูข้อมูลเพิ่มเติมเกี่ยวกับ ประสบการณ์ social sign-in

ใช้ Account API เพื่อสร้างศูนย์บัญชี (Account Center) แบบกำหนดเองในแอปของคุณ ให้ผู้ใช้ที่ลงชื่อเข้าใช้เชื่อมโยงหรือยกเลิกการเชื่อมโยงบัญชีโซเชียลของตน ดูตัวอย่างการใช้งาน Account API

เคล็ดลับ:

สามารถเปิดใช้งานตัวเชื่อมต่อ OIDC เฉพาะสำหรับการเชื่อมโยงบัญชีและการเข้าถึง API โดยไม่ต้องเปิดใช้งานสำหรับ social sign-in ก็ได้

เข้าถึง API ของผู้ให้บริการข้อมูลระบุตัวตนและดำเนินการต่าง ๆ

แอปพลิเคชันของคุณสามารถดึง access token ที่เก็บไว้จาก Secret Vault เพื่อเรียก API ของผู้ให้บริการข้อมูลระบุตัวตนและทำงาน backend อัตโนมัติ ความสามารถเฉพาะขึ้นอยู่กับผู้ให้บริการข้อมูลระบุตัวตนและ scope ที่คุณร้องขอ ดูคู่มือการดึงโทเค็นที่เก็บไว้เพื่อเข้าถึง API

หลังจากผู้ใช้เชื่อมโยงบัญชีโซเชียลแล้ว ผู้ดูแลระบบสามารถจัดการการเชื่อมต่อนั้นใน Logto Console ได้ดังนี้:

ไปที่ Logto console > การจัดการผู้ใช้ และเปิดโปรไฟล์ของผู้ใช้
ในส่วน Social connections ค้นหารายการผู้ให้บริการข้อมูลระบุตัวตนแล้วคลิก จัดการ
ในหน้านี้ ผู้ดูแลระบบสามารถจัดการการเชื่อมต่อโซเชียลของผู้ใช้ ดูข้อมูลโปรไฟล์ทั้งหมดที่ได้รับและซิงค์จากบัญชีโซเชียล และตรวจสอบสถานะ access token

บันทึก:

การตอบกลับ access token ของผู้ให้บริการข้อมูลระบุตัวตนบางรายจะไม่มีข้อมูล scope ที่เฉพาะเจาะจง Logto จึงไม่สามารถแสดงรายการสิทธิ์ที่ผู้ใช้อนุญาตได้โดยตรง อย่างไรก็ตาม ตราบใดที่ผู้ใช้ได้ให้ความยินยอมกับ scope ที่ร้องขอระหว่างการอนุญาต แอปพลิเคชันของคุณจะมีสิทธิ์ที่เกี่ยวข้องเมื่อเข้าถึง OIDC API

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

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

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

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

แท็บประสบการณ์การลงชื่อเข้าใช้ (Sign-in Experience tab)

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

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

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

กระบวนการสำหรับผู้ใช้ปลายทาง: 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 ไปจนถึงหัวข้อขั้นสูงและอื่น ๆ

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

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

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

Carthage​

CocoaPods​

เริ่มต้น LogtoClient​

ลงชื่อเข้าใช้​

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

Configure redirect URI​

Use Universal Links instead of a custom scheme?​

Sign-in and sign-out​

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

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

ตั้งค่า Standard OIDC app​

สร้างแอป OIDC ของคุณ​

กำหนดค่าตัวเชื่อมต่อของคุณ​

ประเภทของ config​

การตั้งค่าทั่วไป​

ชื่อและโลโก้ปุ่มโซเชียล​

ชื่อผู้ให้บริการข้อมูลระบุตัวตน​

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

เก็บโทเค็นเพื่อเข้าถึง API ของบุคคลที่สาม (ไม่บังคับ)​

ใช้งานตัวเชื่อมต่อ OIDC​

เปิดใช้งานปุ่ม social sign-in​

เชื่อมโยงหรือยกเลิกการเชื่อมโยงบัญชีโซเชียล​

เข้าถึง API ของผู้ให้บริการข้อมูลระบุตัวตนและดำเนินการต่าง ๆ​

จัดการข้อมูลระบุตัวตนโซเชียลของผู้ใช้​

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

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

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

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

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

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

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

Carthage

CocoaPods

เริ่มต้น LogtoClient

ลงชื่อเข้าใช้

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

Configure redirect URI

Use Universal Links instead of a custom scheme?

Sign-in and sign-out

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

เพิ่มตัวเชื่อมต่อ OIDC

ตั้งค่า Standard OIDC app

สร้างแอป OIDC ของคุณ

กำหนดค่าตัวเชื่อมต่อของคุณ

ประเภทของ config

การตั้งค่าทั่วไป

ชื่อและโลโก้ปุ่มโซเชียล

ชื่อผู้ให้บริการข้อมูลระบุตัวตน

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

เก็บโทเค็นเพื่อเข้าถึง API ของบุคคลที่สาม (ไม่บังคับ)

ใช้งานตัวเชื่อมต่อ OIDC

เปิดใช้งานปุ่ม social sign-in

เชื่อมโยงหรือยกเลิกการเชื่อมโยงบัญชีโซเชียล

เข้าถึง API ของผู้ให้บริการข้อมูลระบุตัวตนและดำเนินการต่าง ๆ

จัดการข้อมูลระบุตัวตนโซเชียลของผู้ใช้

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

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

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

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