Cyber Security Academy · บทเรียน

OpenID Connect (OIDC)

เพิ่มอัตลักษณ์ไว้บน OAuth

บทเรียน 2 จาก 413 ขั้นตอน

OpenID Connect (OIDC) เป็นบทเรียน Cyber Security Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cyber Security Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดจึงมี OIDC

OpenID Connect คือชั้นข้อมูลประจำตัวแบบบางที่สร้างอยู่บน OAuth 2.0 OAuth ตอบคำถามว่า แอปนี้ทำอะไรได้บ้าง ส่วน OIDC ตอบว่า ผู้ใช้คือใคร

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

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

โทเค็น ID (JWT)

องค์ประกอบสำคัญของ OIDC คือโทเค็น ID ซึ่งเป็น JWT ที่ลงลายมือชื่อและอธิบายเหตุการณ์ยืนยันตัวตน

โทเค็นนี้มีข้อมูลยืนยันเกี่ยวกับ ผู้ใด ที่เข้าสู่ระบบและ เมื่อใด
มีไว้ให้ไคลเอนต์นำไปใช้ ไม่ใช่เซิร์ฟเวอร์ทรัพยากร

ห้ามส่งโทเค็น ID ไปยัง API เพื่อใช้เป็นข้อมูลรับรองการเข้าถึง และห้ามยอมรับโทเค็นดังกล่าวโดยไม่ตรวจสอบลายมือชื่อและข้อมูลยืนยัน

Header.Payload.Signature
{
  "iss": "https://idp.example",
  "sub": "248289761001",
  "aud": "app123",
  "exp": 1718000000,
  "iat": 1717996400,
  "nonce": "n-abc"
}

ข้อมูลยืนยันหลักของโทเค็น ID

การตรวจสอบโทเค็น ID หมายถึงการตรวจสอบข้อมูลยืนยันที่เฉพาะเจาะจง ไม่ใช่ตรวจสอบเพียงลายมือชื่อเท่านั้น

iss ผู้ออกต้องตรงกับ IdP ที่คาดหมาย
aud ผู้รับต้องมี client_id ของคุณอยู่ด้วย
exp / iat โทเค็นต้องยังไม่หมดอายุและต้องออกมาไม่นาน
sub ตัวระบุผู้ใช้ที่คงที่และไม่ซ้ำกัน
nonce ต้องตรงกับค่าที่ไคลเอนต์ของคุณส่งไป

กระบวนการยืนยันตัวตนของ OIDC

OIDC นำกระบวนการรหัสการอนุญาตมาใช้ซ้ำ แต่เพิ่มขอบเขต openid และ nonce

ไคลเอนต์ขอขอบเขต openid (รวมถึง profile และ email ได้ตามต้องการ)
จุดปลายทางโทเค็นส่งโทเค็น ID มาพร้อมกับโทเค็นเข้าถึง
nonce เชื่อมโยงโทเค็น ID กับคำขอต้นฉบับ เพื่อป้องกันการนำกลับมาใช้ซ้ำ

GET /authorize?response_type=code
  &scope=openid profile email
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &state=xyz&nonce=n-abc

การตรวจสอบลายมือชื่อด้วย JWKS

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

ดึงกุญแจจาก jwks_uri และจับคู่กับส่วนหัว kid ของโทเค็น
ตรวจสอบด้วยอัลกอริทึมแบบไม่สมมาตรที่ระบุไว้ (RS256, ES256)

ให้ปฏิเสธอัลกอริทึม none และห้ามเชื่อถือค่าของอัลกอริทึมที่โทเค็นส่งมาเพียงฝ่ายเดียว

GET /.well-known/openid-configuration
  -> { "jwks_uri": "https://idp.example/jwks", ... }
GET /jwks
  -> { "keys": [ { "kid": "k1", "kty": "RSA", ... } ] }

nonce ป้องกันการนำกลับมาใช้ซ้ำ

nonce สำหรับโทเค็น ID ก็ทำหน้าที่เช่นเดียวกับ state สำหรับการเปลี่ยนเส้นทาง นั่นคือเป็นค่าที่ใช้ครั้งเดียวเพื่อผูกการตอบกลับเข้ากับคำขอ

ไคลเอนต์สร้าง nonce แบบสุ่มและเก็บไว้ในเซสชัน
IdP ส่งค่านี้กลับมาอยู่ภายในโทเค็น ID
เมื่อได้รับโทเค็น ไคลเอนต์จะตรวจสอบว่า nonce ตรงกันและยังไม่เคยถูกใช้มาก่อน

วิธีนี้ป้องกันการนำโทเค็นกลับมาใช้ซ้ำและการแทรกโทเค็นที่สร้างขึ้นสำหรับเซสชันอื่น

จุดปลายทาง UserInfo

สำหรับข้อมูลโปรไฟล์เพิ่มเติมนอกเหนือจากโทเค็น ID OIDC กำหนดจุดปลายทาง UserInfo ไว้

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

ต้องจับคู่ค่า sub ที่ส่งกลับมากับค่า sub ในโทเค็น ID เสมอ เพื่อป้องกันการสับเปลี่ยนข้อมูลยืนยัน

GET /userinfo
Authorization: Bearer <access_token>

-> { "sub": "248289761001", "email": "u@example.com" }

การค้นหาและข้อมูลเมตา

OIDC กำหนดมาตรฐานสำหรับการค้นหา เพื่อให้ไคลเอนต์ตั้งค่าจุดปลายทางและฟีเจอร์ที่รองรับได้โดยอัตโนมัติ

เอกสาร /.well-known/openid-configuration แสดงรายการจุดปลายทาง ขอบเขตที่รองรับ และอัลกอริทึม
ตรึงหรือตรวจสอบผู้ออกให้แน่ชัด อย่าติดตามข้อมูลการค้นหาจากโฮสต์ที่ผู้โจมตีควบคุมโดยไม่ตรวจสอบ

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

การออกจากระบบผ่านช่องทางด้านหน้าเทียบกับช่องทางเบื้องหลัง

ข้อกำหนดการออกจากระบบของ OIDC ใช้จัดการการยุติเซสชันระหว่างแอปที่รวมศูนย์การยืนยันตัวตน

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

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

ข้อผิดพลาด OIDC ที่พบบ่อย

ข้อผิดพลาดด้านข้อมูลประจำตัวมักเกิดจากการข้ามขั้นตอนการตรวจสอบ

ยอมรับโทเค็นโดยไม่ตรวจสอบ aud (โทเค็นมีไว้สำหรับไคลเอนต์อื่น)
เพิกเฉยต่อ iss ทำให้สามารถปลอมแปลง IdP ได้
ไม่ตรวจสอบลายมือชื่อหรือยอมรับ alg: none
สับสนระหว่างโทเค็น ID กับโทเค็นเข้าถึง
ไม่ตรวจสอบ nonce ทำให้สามารถนำโทเค็นกลับมาใช้ซ้ำได้

Validation checklist:
  [ ] iss == expected
  [ ] aud contains client_id
  [ ] exp not passed, iat sane
  [ ] signature verified via JWKS
  [ ] nonce matches session

OIDC เทียบกับ OAuth แบบปกติสำหรับการเข้าสู่ระบบ

หากเป้าหมายคือการเข้าสู่ระบบ ให้ใช้ OIDC ไม่ใช่ OAuth โดยตรง

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

ความแตกต่างนี้ป้องกันข้อบกพร่องด้านการยืนยันตัวตนแบบผู้รับมอบหมายที่สับสนซึ่งพบได้ทั่วไป

ตรวจสอบอย่างรวดเร็ว: การตรวจสอบโทเค็น ID

เลือกขั้นตอนการตรวจสอบที่สำคัญที่สุดสำหรับฝ่ายที่พึ่งพาซึ่งนำโทเค็น ID ไปใช้

ตอบคำถามในบทเรียนแบบโต้ตอบ

สรุปทบทวน: OpenID Connect

ประเด็นสำคัญ:

OIDC เพิ่มชั้นข้อมูลประจำตัวบน OAuth 2.0 โดยโทเค็น ID คือ JWT ที่ลงลายมือชื่อเพื่อยืนยันการยืนยันตัวตน
ต้องตรวจสอบ iss, aud, exp, ลายมือชื่อ (ผ่าน JWKS) และ nonce เสมอ
โทเค็น ID มีไว้สำหรับไคลเอนต์ ส่วนโทเค็นเข้าถึงมีไว้สำหรับ API ห้ามสลับหน้าที่กัน
ใช้ nonce ป้องกันการนำกลับมาใช้ซ้ำ และใช้ state ป้องกัน CSRF
ใช้ OIDC ไม่ใช่ OAuth โดยตรง เมื่อต้องการยืนยันตัวตนผู้ใช้

เริ่มต้นได้ฟรี

เรียนรู้ Cyber Security Academy ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส: 76
บทเรียน: 303

เริ่มเรียนฟรี ดูหลักสูตรเต็ม

คำถามที่พบบ่อย

บทเรียน “OpenID Connect (OIDC)” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “OpenID Connect (OIDC)” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cyber Security Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “OpenID Connect (OIDC)”

เพิ่มอัตลักษณ์ไว้บน OAuth คุณปฏิบัติ Cyber Security Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cyber Security Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cyber Security Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “OpenID Connect (OIDC)” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cyber Security Academy นี้ได้ไหม

ได้ บทเรียน Cyber Security Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Cyber Security Academy