จดหมายถึงผู้ให้บริการ OAuth

 (pilcrowonpaper.com)
1 คะแนน โดย GN⁺ 2024-12-13 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

  • จดหมายถึงผู้ให้บริการ OAuth

    • GitHub

      • token endpoint ส่งคืนรหัสสถานะ 200 แม้เกิดข้อผิดพลาด
      • การตอบกลับเมื่อเกิดข้อผิดพลาดควรใช้รหัสสถานะ 400 หรือ 401

    • Facebook

      • token endpoint ส่งคืนการตอบกลับข้อผิดพลาดแบบกำหนดเอง
      • ควรเป็นอ็อบเจ็กต์ JSON ที่มีฟิลด์ error

    • TikTok

      • เซิร์ฟเวอร์ใช้พารามิเตอร์ client_key แทน client_id
      • ไม่มีเหตุผลที่อธิบายการเบี่ยงเบนจากข้อกำหนดนี้

    • Strava

      • เซิร์ฟเวอร์ใช้รายการที่คั่นด้วยจุลภาคสำหรับพารามิเตอร์ scope
      • ควรเป็นรายการที่คั่นด้วยช่องว่าง

    • Naver

      • เซิร์ฟเวอร์ส่งคืนเวลาหมดอายุของโทเค็นเป็นสตริง
      • นี่เป็นปัญหาที่เกินกว่าประเด็นเรื่องการปฏิบัติตามข้อกำหนด

    • ผู้ให้บริการ OAuth หลายราย

      • ควรรองรับ HTTP Basic authentication แทนการใช้พารามิเตอร์ client_secret สำหรับการยืนยันตัวตนของไคลเอนต์
      • ในมาตรฐาน OAuth 2.1 นั้น HTTP Basic authentication เป็นทางเลือก แต่แม้จะกำหนดให้ใช้ PKCE ผู้ให้บริการส่วนใหญ่ก็ยังไม่ใช้

    • AWS

      • เคยได้รับรายงานบั๊กหลายรายการเมื่อใช้ร่วมกับไลบรารี OAuth client แต่ไม่สามารถทำซ้ำปัญหาได้ จึงลบเนื้อหาที่เกี่ยวข้องออก

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
rikko 2024-12-13

ระหว่างสร้างโปรเจ็กต์บริการภาครัฐสำหรับประชาชน ผมเคยมีประสบการณ์ที่ต้องใช้เวลาเต็ม ๆ 1 เดือนแค่กับการทำฟังก์ชัน OAuth (OIDC)...

เพราะใช้ไลบรารีภายนอกไม่ได้ เลยต้องลงมือทำเองทุกอย่างทีละส่วน แต่ถ้าพูดถึงการทำตามมาตรฐาน OAuth ได้อย่างถูกต้อง ก็มีแค่ Kakao กับ Google เท่านั้น...

ส่วน Naver ก็ประมาณว่าแค่ล็อกอินได้ก็ไม่มีปัญหา ระดับที่ไม่แน่ใจด้วยซ้ำว่าควรใช้ดีไหม และ Apple ก็ต้องใช้โค้ดสำหรับการติดตั้งมากกว่าซอร์ส OAuth เดิมเกิน 3 เท่า จนทุกวันนี้นึกย้อนกลับไปก็ยังจำไม่ได้เลยว่าตอนนั้นทำมันขึ้นมาได้ยังไง

บางเจ้าก็มีเคสที่ response code พังยับอย่างในบทความด้านบน และหนักเข้าจนถึงขั้นมีผู้ให้บริการที่ตอบกลับ 418 (I'm a teapot) มาด้วย
พอมีประสบการณ์แบบนี้ ผมเลยต่อให้ฟีเจอร์อย่าง social login จะสะดวกแค่ไหน ก็เลิกอยากใช้มันไปเลย...
 
GN⁺ 2024-12-13
ความคิดเห็นจาก Hacker News

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

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

  • เมื่อ 1 ปีก่อนได้ทำ OAuth ให้กับ API ยอดนิยม 100 รายการ และประสบการณ์ก็คล้ายกับที่ OP อธิบายไว้

  • ผู้ให้บริการจำนวนมากไม่รองรับ prompt=select_account หรือไม่ให้ผู้ใช้เลือกบัญชีที่จะใช้ล็อกอิน ซึ่งเป็นปัญหาอย่างยิ่งใน OIDC

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

  • ถ้ามีชุดทดสอบอย่างเป็นทางการ ก็จะช่วยการพัฒนามาตรฐานเปิดได้มาก เนื่องจากติดตามสเปกได้ยาก การมีชุดทดสอบที่ใช้ตรวจสอบได้จึงเป็นประโยชน์

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

  • ผู้ให้บริการบางรายไม่ทำตามสเปก และเลือกใช้เอนด์พอยต์แยกต่างหากสำหรับ refresh token

  • มีการเรียกร้องให้ผู้ให้บริการ OIDC/OAuth รองรับ SCIM อย่างเหมาะสม และออกแบบระบบด้วยแนวคิด "API-first" ก่อนจะย้ายไป GNAP ควรทบทวนการตัดสินใจอีกครั้ง