OpenID Connect: คืออะไร โปรโตคอลการยืนยันตัวตนและการอนุญาต

OpenID Connect คืออะไร?

OpenID Connect (OIDC) เป็นโปรโตคอลการยืนยันตัวตนแบบเปิดที่สร้างขึ้นเป็นส่วนขยายบน OAuth 2.0 โดยทำให้สิ่งที่ OAuth 2.0 ขาดหายไปเป็นมาตรฐาน: การตรวจสอบตัวตนผู้ใช้ ถ้า OAuth 2.0 ตอบคำถาม “แอปพลิเคชันใดมีสิทธิ์เข้าถึง?” ดังนั้น OIDC จะตอบ “ผู้ใช้คนนี้คือใคร?”

โปรโตคอลใช้ ID Token — JSON Web Token (JWT) ที่มีชุดของ Claims: ตัวระบุหัวข้อที่ไม่ซ้ำกัน, อีเมล, ชื่อ, รูปประจำตัว, ประทับเวลาการออกและหมดอายุ แอปพลิเคชันไคลเอ็นต์สามารถตรวจสอบ ID Token ด้วยการเข้ารหัส — เซิร์ฟเวอร์ลงนามในโทเค็นด้วย RS256 หรือ ES256 และไคลเอ็นต์ตรวจสอบลายเซ็นกับคีย์สาธารณะที่ได้รับผ่านปลายทาง JWKS

ตามข้อมูลของ Auth0, 2025 แอปมือถือมากกว่า 78% ที่ใช้การยืนยันตัวตนของบุคคลที่สามใช้ OIDC ผ่าน Google Sign-In หรือ Sign in with Apple ซึ่งทำให้โปรโตคอลนี้เป็นมาตรฐานโดยพฤตินัยสำหรับการเข้าสู่ระบบทางสังคมและการยืนยันตัวตนขององค์กร

OpenID Connect ทำงานอย่างไร

OpenID Connect กำหนดโฟลว์หลายแบบขึ้นอยู่กับประเภทของไคลเอ็นต์ สำหรับแอปพลิเคชันมือถือ มาตรฐานคือ Authorization Code Flow พร้อม Proof Key for Code Exchange (PKCE) — ซึ่งให้ความปลอดภัยแม้ไม่มี client secret บนอุปกรณ์

ผู้ให้บริการตัวตนและบทบาทของมัน

ผู้ให้บริการตัวตน (IdP) คือเซิร์ฟเวอร์ที่ทำการยืนยันตัวตนผู้ใช้และออกโทเค็น ในระบบนิเวศ OIDC IdP มีปลายทางหลักสองแห่ง: Authorization Endpoint สำหรับให้ผู้ใช้เข้าสู่ระบบและ Token Endpoint สำหรับแลกเปลี่ยนรหัสเป็นโทเค็น ไคลเอ็นต์ค้นหาที่อยู่ของปลายทางเหล่านี้ผ่าน Discovery URL — เส้นทางมาตรฐาน /.well-known/openid-configuration ซึ่งส่งคืนเอกสาร JSON พร้อมการกำหนดค่าผู้ให้บริการทั้งหมด

แต่ละ IdP เผยแพร่ JWKS (JSON Web Key Set) — ชุดของคีย์สาธารณะสำหรับตรวจสอบลายเซ็น ID Token ไคลเอ็นต์แคชคีย์เหล่านี้และใช้เพื่อตรวจสอบแต่ละโทเค็นที่ได้รับโดยไม่ต้องติดต่อเซิร์ฟเวอร์

Authorization Code Flow กับ PKCE

Authorization Code Flow เป็นกระบวนการสามขั้นตอน ขั้นแรก แอปพลิเคชันมือถือสร้าง code verifier (สตริงสุ่มยาว 43–128 ตัวอักษร) และแฮชของมัน — code challenge แอปพลิเคชันเปิดเบราว์เซอร์หรือ WebView ด้วย URL ที่มี client_id, redirect_uri, scope (openid profile email) และ code challenge ผู้ใช้ป้อนข้อมูลรับรองบนหน้า IdP และยืนยันความยินยอม IdP เปลี่ยนเส้นทางเบราว์เซอร์กลับไปยังแอปพลิเคชันพร้อม authorization code

ในขั้นตอนที่สอง แอปพลิเคชันส่ง authorization code, code verifier และ client_id ไปยัง Token Endpoint ของเซิร์ฟเวอร์ เซิร์ฟเวอร์ตรวจสอบ code verifier กับ code challenge ที่เก็บไว้และส่งคืน ID Token, Access Token และอาจส่งคืน Refresh Token ในขั้นตอนที่สาม แอปพลิเคชัน ตรวจสอบ ID Token: ตรวจสอบความถูกต้องของลายเซ็นกับ JWKS, ตรวจสอบ issuer (iss), audience (aud) และเวลาหมดอายุ (exp) หากการตรวจสอบผ่าน ผู้ใช้จะถือว่าได้รับการยืนยันตัวตนแล้ว

PKCE (Proof Key for Code Exchange) ขจัดช่องโหว่ที่มีอยู่ใน Authorization Code Flow มาตรฐานสำหรับไคลเอ็นต์สาธารณะ เนื่องจากแอปพลิเคชันมือถือไม่สามารถจัดเก็บ client secret ได้อย่างปลอดภัย ผู้โจมตีที่สกัดกั้น authorization code อาจแลกเปลี่ยนเป็นโทเค็นได้ Code verifier แก้ปัญหานี้: แม้ว่ารหัสจะถูกสกัดกั้น หากไม่มี code verifier ดั้งเดิม การแลกเปลี่ยนจะเป็นไปไม่ได้ OAuth Security Best Practices (RFC 9700) กำหนดให้ใช้ PKCE สำหรับไคลเอ็นต์สาธารณะทั้งหมด รวมถึงแอปพลิเคชันมือถือ

ID Token และ Access Token

OpenID Connect ส่งคืนโทเค็นที่แตกต่างกันโดยพื้นฐานสองแบบ: ID Token และ Access Token ID Token เป็น JWT เสมอที่ไคลเอ็นต์สามารถอ่านและตรวจสอบได้ด้วยตนเอง โดยมีข้อมูลผู้ใช้และใช้สำหรับการยืนยันตัวตน ไม่ใช่สำหรับการเข้าถึง API

โครงสร้างของ ID Token

ID Token ประกอบด้วย header, payload และ signature ที่เข้ารหัสใน Base64 และคั่นด้วยจุด header มี alg (อัลกอริทึมลายเซ็น) และ kid (ตัวระบุคีย์) payload รวมถึง Claims ที่จำเป็น: iss (issuer), sub (subject — ID ผู้ใช้ที่ไม่ซ้ำกัน), aud (audience — ตัวระบุไคลเอ็นต์), exp (expiration), iat (issued at) Claims ที่ไม่บังคับรวมถึง name, email, picture, locale

ตัวอย่าง payload ของ ID Token ที่ถอดรหัสจาก Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

Access Token คือโทเค็นทึบแสง (สตริงตามอำเภอใจ) หรือ JWT ที่ไคลเอ็นต์ส่งในคำขอ API แตกต่างจาก ID Token ตรงที่ access token ไม่ได้ออกแบบมาให้ไคลเอ็นต์อ่าน — รูปแบบและเนื้อหาของมันรู้เฉพาะเซิร์ฟเวอร์ทรัพยากรและเซิร์ฟเวอร์อนุญาตเท่านั้น Access Token มีขอบเขต (scope) — ข้อจำกัดสิทธิ์ — และอายุสั้น โดยทั่วไป 15–60 นาที

ความแตกต่างระหว่าง OpenID Connect และ OAuth 2.0

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

เมื่อใดควรเลือก OpenID Connect

OpenID Connect จำเป็นเมื่อแอปพลิเคชันต้องการ ระบุตัวตนผู้ใช้ ไม่ใช่แค่เข้าถึงข้อมูลของพวกเขา หากคุณใช้ “เข้าสู่ระบบด้วย Google” หรือ “เข้าสู่ระบบด้วย Apple” — นั่นคือ OIDC หากแอปพลิเคชันของคุณเรียก API ของบุคคลที่สามในนามของผู้ใช้โดยไม่จำเป็นต้องรู้ตัวตนของพวกเขา — OAuth 2.0 บริสุทธิ์ก็เพียงพอ สำหรับระบบองค์กรที่มี Single Sign-On (SSO) ตัวเลือกนั้นชัดเจน: มีเพียง OpenID Connect เท่านั้น เนื่องจากให้การออกจากระบบที่เป็นมาตรฐานและการจัดการเซสชัน

การนำ OpenID Connect ไปใช้ในแอปพลิเคชันมือถือ

การผสาน OpenID Connect เข้ากับแอปพลิเคชันมือถือต้องเลือกไลบรารีที่เหมาะสมและกำหนดค่าโฟลว์อย่างถูกต้อง สำหรับ Android ให้ใช้ ตัวจัดการข้อมูลรับรอง (AndroidX Credentials) หรือไลบรารี AppAuth สำหรับ iOS ให้ใช้เฟรมเวิร์ก AuthenticationServices กับ ASWebAuthenticationSession

ตัวอย่างโค้ด Kotlin (Android)

ด้านล่างเป็นตัวอย่างการเริ่ม Authorization Code Flow โดยใช้ไลบรารี AppAuth-Android แอปพลิเคชันสร้างคำขออนุญาต เปิดเบราว์เซอร์สำหรับให้ผู้ใช้เข้าสู่ระบบ และจัดการ callback กับโทเค็น

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

ตัวอย่างโค้ด Swift (iOS)

ASWebAuthenticationSession ของ Apple มีเบราว์เซอร์ในตัวสำหรับโฟลว์ OIDC พร้อมรองรับ SSO ผ่าน iCloud Keychain เซสชันเริ่มต้นด้วย URL การอนุญาต และ callback จะถูกจัดการผ่าน completion handler

เมื่อเลือกไลบรารีสำหรับ OpenID Connect ให้พิจารณาการรองรับ PKCE ในตัว: AppAuth-Android และ AppAuth-iOS รองรับ PKCE โดยค่าเริ่มต้น Firebase Authentication ใช้ OIDC ภายในสำหรับ Google Sign-In, Sign in with Apple และ Microsoft — นักพัฒนาไม่จำเป็นต้องใช้โฟลว์ด้วยตนเอง สำหรับระบบองค์กรที่มี IdP ที่กำหนดเอง (เช่น Keycloak หรือ Okta) AppAuth ยังคงเป็นตัวเลือกมาตรฐานพร้อมการควบคุมการกำหนดค่าและการจัดการข้อผิดพลาดอย่างเต็มที่

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()