Cyber Security Academy · บทเรียน

โฟลว์ OAuth 2.0

การอนุญาตและโทเค็น

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

OAuth 2.0 แก้ปัญหาอะไรจริง ๆ

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

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

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

บทบาททั้งสี่

ทุกกระบวนการของ OAuth เกี่ยวข้องกับบทบาทสี่บทบาท การระบุบทบาทให้ถูกต้องเป็นสิ่งสำคัญต่อการสร้างแบบจำลองภัยคุกคาม

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

ขอบเขตความน่าเชื่อถืออยู่ระหว่างบทบาทเหล่านี้ ไคลเอ็นต์ที่ถูกเจาะหรือ AS ที่อนุญาตกว้างเกินไปจะบั่นทอนห่วงโซ่ทั้งหมด

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

การให้สิทธิ์ด้วยรหัสการอนุญาต

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

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

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

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE: คีย์พิสูจน์สำหรับการแลกเปลี่ยนรหัส

PKCE (RFC 7636) เพิ่มความแข็งแกร่งให้การให้สิทธิ์ด้วยรหัสการอนุญาต และปัจจุบันแนะนำให้ใช้กับไคลเอ็นต์ทุกประเภท รวมถึงไคลเอ็นต์แบบเก็บความลับ

ไคลเอ็นต์สร้าง code_verifier แบบสุ่ม และส่งค่าแฮชของมันเป็น code_challenge
ในขั้นแลกเปลี่ยนโทเค็น ไคลเอ็นต์ต้องแสดงตัวตรวจสอบเดิม

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

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

การให้สิทธิ์ด้วยข้อมูลรับรองไคลเอ็นต์

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

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

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

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

โทเค็นการเข้าถึงเทียบกับโทเค็นต่ออายุ

OAuth ออกโทเค็นหลักสองประเภท ซึ่งมีอายุการใช้งานและกฎการจัดการแตกต่างกันมาก

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

โทเค็นต่ออายุมีมูลค่าสูง จัดเก็บอย่างปลอดภัย ผูกโทเค็นกับไคลเอ็นต์ และรองรับการเพิกถอน

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

โทเค็นแบบผู้ถือและการรับส่งข้อมูล

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

ส่งผ่าน TLS เสมอ ห้ามส่งไว้ใน URL เพราะอาจรั่วไหลไปยังบันทึกและข้อมูลผู้อ้างอิง
ส่งผ่านส่วนหัว Authorization
พิจารณาใช้โทเค็นที่ผูกกับผู้ส่ง (DPoP, mTLS) สำหรับ API ที่มีความเสี่ยงสูง

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

การให้สิทธิ์แบบแฝงเลิกใช้งานแล้ว

การให้สิทธิ์แบบ Implicit รุ่นเก่าจะส่งโทเค็นกลับมาโดยตรงในส่วน fragment ของ URI เปลี่ยนเส้นทาง ปัจจุบัน OAuth 2.0 Security BCP ไม่แนะนำให้ใช้แล้ว และถูกถอดออกจาก OAuth 2.1

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

สำหรับ SPA ควรใช้ รหัสการอนุญาตร่วมกับ PKCE แทน

พารามิเตอร์ state และ CSRF

พารามิเตอร์ state ป้องกันขั้นตอนเปลี่ยนเส้นทางจาก CSRF ไคลเอนต์จะสร้างค่าสุ่ม เก็บค่าไว้ในเซสชัน และตรวจสอบค่าเมื่อมีการเรียกกลับ

หากค่า state ที่ส่งกลับมาไม่ตรงกัน ให้ปฏิเสธการตอบกลับนั้น
วิธีนี้ป้องกันไม่ให้ผู้โจมตีแทรกรหัสการอนุญาตของตนเองเข้าไปในเซสชันของเหยื่อ

before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

ขอบเขตการเข้าถึงและสิทธิ์เท่าที่จำเป็น

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

ขอเฉพาะขอบเขตการเข้าถึงที่ฟีเจอร์ต้องใช้ (read:profile ไม่ใช่ admin)
เซิร์ฟเวอร์ทรัพยากรต้องบังคับใช้ขอบเขตการเข้าถึงกับทุกจุดปลายทาง ไม่ใช่เพียงเชื่อว่าโทเค็นที่ถูกต้องจะปลอดภัย

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

การตั้งค่า OAuth ที่ผิดพลาดทั่วไป

เหตุการณ์ด้าน OAuth ส่วนใหญ่เกิดจากการตั้งค่า ไม่ใช่จากตัวโพรโทคอลเอง

การเปลี่ยนเส้นทางแบบเปิด / การจับคู่ redirect_uri ที่ไม่รัดกุม เปิดโอกาสให้ผู้โจมตีขโมยรหัสได้
การไม่มี state หรือ PKCE เปิดช่องให้เกิด CSRF และการแทรกรหัส
โทเค็นเข้าถึงมีอายุยาวนานโดยไม่มีการเพิกถอน
ถือว่าโทเค็นเข้าถึงเป็นข้อมูลยืนยันตัวตน

ควรลงทะเบียน URI เปลี่ยนเส้นทางให้ตรงทุกประการและตรวจสอบอย่างเคร่งครัด

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

ตรวจสอบอย่างรวดเร็ว: การรักษาความปลอดภัยของการยืนยันตัวตน SPA

เลือกกระบวนการสมัยใหม่ที่ถูกต้องสำหรับสถานการณ์ต่อไปนี้

สรุปทบทวน: กระบวนการ OAuth 2.0

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

OAuth 2.0 คือการให้สิทธิ์โดยมอบหมาย ไม่ใช่การยืนยันตัวตน
มีบทบาทสี่ส่วน ได้แก่ เจ้าของทรัพยากร ไคลเอนต์ เซิร์ฟเวอร์การอนุญาต และเซิร์ฟเวอร์ทรัพยากร
รหัสการอนุญาต + PKCE เป็นค่าเริ่มต้นสำหรับเว็บ อุปกรณ์เคลื่อนที่ และ SPA
ข้อมูลรับรองไคลเอนต์ รองรับการเข้าถึงระหว่างเครื่องกับเครื่อง
ป้องกันด้วย state การจับคู่ URI เปลี่ยนเส้นทางอย่างเคร่งครัด โทเค็นเข้าถึงอายุสั้น และ TLS ในทุกจุด
การให้สิทธิ์แบบ Implicit และแบบรหัสผ่านเลิกใช้งานแล้ว

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

บทเรียน “โฟลว์ OAuth 2.0” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “โฟลว์ OAuth 2.0”

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

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

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

บทเรียน “โฟลว์ OAuth 2.0” ใช้เวลานานแค่ไหน

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

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

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

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

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