OAuth คืออะไร? "Sign in with Google" และการให้สิทธิ์แทนอธิบายแบบเข้าใจง่าย

OAuth คือมาตรฐานเปิดที่ให้ผู้ใช้มอบสิทธิ์เข้าถึงบัญชีของตนในบริการหนึ่งแก่แอปหนึ่งได้อย่างจำกัด โดยไม่ต้องส่งรหัสผ่านให้ เมื่อคุณคลิก “Connect Google Calendar” แล้วเห็นหน้าจอถามว่า “อนุญาตให้แอปนี้เห็นกิจกรรมของคุณไหม?” นั่นคือ OAuth แอปจะได้โทเค็นสำหรับสิ่งที่คุณอนุมัติเท่านั้น และคุณเพิกถอนได้ทุกเมื่อ กลไกเดียวกันนี้พร้อมชั้นเพิ่มเติมที่เรียกว่า OpenID Connect ขับเคลื่อนปุ่ม “Sign in with Google” และปุ่มที่คล้ายกัน

ทำไม OAuth จึงสำคัญเมื่อสร้างด้วย AI

OAuth ปรากฏในสองสถานการณ์ที่พบบ่อยเมื่อคุณสร้างแอป:

1. ล็อกอินผ่านโซเชียล คุณอยากให้ผู้ใช้ “Sign in with Google” (หรือ Apple, Microsoft, GitHub) แทนการสร้างรหัสผ่านอีกชุด ดูวิธีเพิ่มการล็อกอินให้แอปของคุณ
2. เชื่อมต่อกับบัญชีของผู้ใช้บนบริการอื่น แอปของคุณต้องอ่านปฏิทินของผู้ใช้ โพสต์ไปยังบัญชีโซเชียลของเขา ดึงไฟล์จากไดรฟ์คลาวด์ หรือซิงก์ข้อมูลบัญชี

ในทั้งสองกรณี เครื่องมือสร้างแอป AI เขียนโค้ดให้ได้ แต่มีบางขั้นตอนที่มีแค่คุณทำได้ เช่น สร้างแอปนักพัฒนากับผู้ให้บริการ รับ client ID และ client secret ลงทะเบียน callback URL และสำหรับสิทธิ์บางอย่าง ต้องผ่านการรีวิวของผู้ให้บริการ การรู้ว่า OAuth ทำงานอย่างไรทำให้ขั้นตอนเหล่านั้น และข้อผิดพลาดที่เกิดขึ้น ไม่น่ากลัวนัก ภาพรวมที่กว้างขึ้นของการล็อกอิน ดูการยืนยันตัวตนคืออะไร

เปรียบเทียบแบบในชีวิตประจำวัน

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

• เคาน์เตอร์ต้อนรับ คือ authorization server (หน้าล็อกอินของ Google)
• การตรวจบัตรของคุณ คือการที่คุณล็อกอินเข้า Google
• คีย์การ์ด คือ access token
• “เฉพาะห้องและฟิตเนส” คือ scope ที่คุณอนุมัติ
• เช็กเอาท์ คือโทเค็นหมดอายุ หรือคุณเพิกถอนการเข้าถึง

แอปที่คุณใช้ไม่เคยเห็นรหัสผ่าน Google ของคุณ เห็นแค่การ์ดคีย์เท่านั้น

OAuth ทำงานทีละขั้นตอนอย่างไร

ขั้นตอนที่พบบ่อยที่สุดสำหรับเว็บแอปคือ authorization code flow นี่คือสิ่งที่เกิดขึ้นเมื่อผู้ใช้เชื่อม Google Calendar กับแอปจัดตาราง:

1. คลิก ผู้ใช้คลิก “Connect Google Calendar”
2. redirect ไปยังผู้ให้บริการ แอปส่งเบราว์เซอร์ไปที่ Google พร้อม client ID, scope ที่ต้องการ (อ่านกิจกรรมปฏิทิน) และ redirect URI ที่ Google ควรส่งผู้ใช้กลับมา
3. ล็อกอินและยินยอม ผู้ใช้ล็อกอิน Google (ถ้ายังไม่ได้ล็อกอิน) และเห็นหน้ายินยอมที่แสดงสิ่งที่แอปขอ แล้วคลิก Allow
4. กลับมาพร้อมรหัส Google redirect เบราว์เซอร์กลับไปยัง redirect URI ของแอป พร้อม authorization code ที่มีอายุสั้นและใช้ได้ครั้งเดียว
5. แลกบนเซิร์ฟเวอร์ เซิร์ฟเวอร์ของแอปส่งรหัสนั้น พร้อม client secret ตรงไปยัง Google และได้รับ access token (และมักได้ refresh token ด้วย)
6. ใช้ API เซิร์ฟเวอร์เรียก API ของ Google Calendar ด้วย access token และได้กิจกรรมของผู้ใช้

Callback ในขั้นตอนที่ 4 มีหน้าตาประมาณนี้:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

และการตอบกลับโทเค็นในขั้นตอนที่ 5 เป็น JSON ประมาณนี้:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

ประเด็นสำคัญในการออกแบบคือ การแลกโทเค็นเกิดขึ้นจากเซิร์ฟเวอร์ไปยังเซิร์ฟเวอร์ ดังนั้น client secret และโทเค็นไม่จำเป็นต้องผ่านเบราว์เซอร์เลย

OAuth กับ OpenID Connect กับการล็อกอินของคุณเอง

แอปจำนวนมากรวมสิ่งเหล่านี้เข้าด้วยกัน: ล็อกอินด้วยอีเมลและรหัสผ่าน บวก “Sign in with Google” ผ่าน OIDC บวกการเชื่อมต่อ OAuth แยกไปยังบริการอื่น

คำศัพท์สำคัญ

ความเข้าใจผิดที่พบบ่อย

• “OAuth คือระบบล็อกอิน” OAuth ธรรมดาให้สิทธิ์เข้าถึง OpenID Connect จัดการเรื่องตัวตน การใช้ access token ดิบเป็นหลักฐานว่าใครเป็นใครเคยทำให้เกิดบั๊กความปลอดภัยจริงมาแล้ว
• “แอปได้รหัสผ่านของฉันไป” ไม่เคยเกิดขึ้น นั่นคือจุดประสงค์
• “ขอ scope เพิ่มก็ไม่มีอันตราย” ผู้ใช้ระวังคำขอที่กว้างมากขึ้น และผู้ให้บริการอย่าง Google อาจต้องให้แอปผ่านการรีวิวสำหรับ scope ที่ละเอียดอ่อนหรือจำกัด ขอเฉพาะสิ่งที่คุณต้องใช้
• “client secret ใส่ไว้ใน frontend ได้” โค้ดในเบราว์เซอร์เป็นสาธารณะทั้งหมด เก็บไว้ในความลับฝั่งเซิร์ฟเวอร์
• “ทำงานตอนทดสอบ ก็จะทำงานบนโปรดักชัน” ผู้ให้บริการมักจำกัดแอปที่ยังไม่ได้รับการยืนยัน เช่น จำกัดเฉพาะผู้ใช้ทดสอบที่ระบุไว้ และ redirect URL ของโดเมนจริงต้องลงทะเบียนแยกต่างหาก
• “โทเค็นอยู่ได้ตลอดไป” access token หมดอายุเร็ว และผู้ใช้เพิกถอนการเข้าถึงได้ แอปของคุณต้องรับมือทั้งสองกรณีอย่างเหมาะสม

สิ่งที่ควรขอจากเครื่องมือสร้างแอป AI ของคุณ

• “เพิ่ม ‘Sign in with Google’ โดยใช้ OpenID Connect และไลบรารียืนยันตัวตนที่ได้รับการดูแลดี อย่าเขียน flow OAuth เองตั้งแต่ต้น”
• “ใช้ authorization code flow ร่วมกับ PKCE และตรวจพารามิเตอร์ state”
• “อ่าน client ID และ client secret จากตัวแปรสภาพแวดล้อมบนเซิร์ฟเวอร์”
• “ขอเฉพาะ scope ที่เราต้องใช้: สิทธิ์อ่านปฏิทินอย่างเดียว”
• “บอกฉันทุก redirect URL ที่ต้องลงทะเบียนในคอนโซลของผู้ให้บริการ สำหรับพรีวิว URL ที่เผยแพร่แล้ว และโดเมนที่กำหนดเองของฉัน”
• “เก็บ refresh token แบบเข้ารหัสในฐานข้อมูล และจัดการโทเค็นที่หมดอายุหรือถูกเพิกถอนด้วยการขอให้ผู้ใช้เชื่อมต่อใหม่”
• “ให้ผู้ใช้ตัดการเชื่อมต่อ integration จากหน้าการตั้งค่าของพวกเขาได้”

OAuth และ Mythex

Mythex ไม่มีระบบล็อกอินสำเร็จรูปสำหรับผู้ใช้ปลายทางของแอปที่คุณสร้าง เอกสารอธิบายแนวทาง bring-your-own คุณเลือกไลบรารียืนยันตัวตนหรือบริการที่โฮสต์ไว้ให้ เก็บคีย์ของมันเป็นความลับของโปรเจกต์ และเอเจนต์เขียนโค้ดให้ สูตรเพิ่มการยืนยันตัวตน มีพรอมต์เริ่มต้นสำหรับเรื่องนี้ คุณจะเจอ OAuth ใน Mythex เองด้วย: คุณลงชื่อเข้าใช้ด้วย Google ได้ การเชื่อมต่อ GitHub เพื่อซิงก์ repo ใช้ GitHub OAuth และเครื่องมือ AI ที่เชื่อมต่อกับ Mythex ผ่าน MCP จะไปผ่านหน้ายินยอม OAuth ดูการยืนยันตัวตนคืออะไร และการยืนยันตัวตนสองขั้นตอนคืออะไร เพิ่มเติม

คำถาม