Google ยุติการรองรับ Google Sync และแอปที่ใช้รหัสผ่านอย่างเดียว
(workspaceupdates.googleblog.com)- Google Workspace จะยุติวิธีการเข้าสู่ระบบแบบ Less Secure Apps (LSA) ที่ใช้เพียงชื่อผู้ใช้และรหัสผ่านร่วมกัน และกำหนดให้ใช้ การเข้าสู่ระบบแบบ OAuth สำหรับการซิงก์อีเมล ปฏิทิน และรายชื่อติดต่อ
- กำหนดการยุติเริ่มต้นเป็น 2 ระยะในวันที่ 15 มิถุนายน 2024 และ 30 กันยายน 2024 แต่หลังจากมีการหยุดและกลับมาเริ่ม rollout ใหม่อีกครั้ง จึงได้ข้อสรุปว่า ตั้งแต่ 1 พฤษภาคม 2025 เป็นต้นไปจะไม่รองรับ LSA อีกต่อไป
- การเชื่อมต่อ CalDAV, CardDAV, IMAP, SMTP, POP และ Google Sync ที่ใช้รหัสผ่านอย่างเดียวได้รับผลกระทบ โดยทั้งผู้ใช้ Google Sync รายใหม่และรายเดิมต่างก็ต้องย้ายระบบ
- ผู้ดูแลระบบควรแชร์แนวทางการย้ายไปใช้ OAuth ให้กับผู้ใช้ที่ได้รับผลกระทบ และโปรไฟล์แบบใช้รหัสผ่านที่เคยแจกจ่ายผ่าน MDM ก็ต้องเปลี่ยนเป็นการ เพิ่ม Google Account ใหม่อีกครั้งด้วย OAuth
- ผู้ใช้ที่ไม่ดำเนินการก่อนวันยุติจะไม่สามารถเข้าสู่ระบบได้และจะพบข้อผิดพลาดว่าชุดชื่อผู้ใช้-รหัสผ่านไม่ถูกต้อง ส่วนนักพัฒนาต้องอัปเดตวิธีเชื่อมต่อของแอปเป็น OAuth 2.0 เพื่อให้ยังใช้งานร่วมกับ Workspace ได้
ยุติวิธีเข้าสู่ระบบที่ใช้รหัสผ่านอย่างเดียว
- Google Workspace จะไม่รองรับวิธีเข้าสู่ระบบที่แอปหรืออุปกรณ์ของบุคคลที่สามขอชื่อผู้ใช้และรหัสผ่าน Google โดยตรงอีกต่อไป
- วิธีนี้เรียกว่า Less Secure Apps (LSA) และเพิ่มความเสี่ยงต่อการเข้าถึงบัญชีโดยไม่ได้รับอนุญาต เพราะต้องแชร์ข้อมูลรับรองบัญชี Google ให้กับแอปและอุปกรณ์ของบุคคลที่สาม
- วิธีทดแทนคือ Sign in with Google ซึ่งใช้ OAuth มาตรฐานการยืนยันตัวตนระดับอุตสาหกรรมที่แอปและอุปกรณ์ของบุคคลที่สามส่วนใหญ่ใช้อยู่แล้ว
- Google ประกาศการเปลี่ยนแปลงนี้ตั้งแต่ปี 2019 และได้เผยแพร่กำหนดการบังคับใช้อีกครั้งในภายหลัง
กำหนดการยุติและประวัติการเลื่อน
- เดิมการยุติการเข้าถึงแบบ LSA แบ่งเป็น 2 ระยะ
- ตั้งแต่ 15 มิถุนายน 2024 การตั้งค่า LSA ใน Admin Console จะถูกนำออกและไม่สามารถเปลี่ยนแปลงได้อีก
- ผู้ใช้ที่เปิดใช้งานไว้แล้วจะยังคงเชื่อมต่อได้ แต่ผู้ใช้ที่ถูกปิดใช้งานจะไม่สามารถเข้าถึง LSA ได้
- ครอบคลุมแอปของบุคคลที่สามที่ใช้ CalDAV, CardDAV, IMAP, SMTP, POP เพื่อเข้าถึง Gmail, Google Calendar และ Contacts ด้วยรหัสผ่านอย่างเดียว
- การตั้งค่าเปิด/ปิด IMAP ในการตั้งค่า Gmail ของผู้ใช้จะถูกนำออกเช่นกัน
- ผู้ใช้ที่ใช้ LSA อยู่ก่อนวันที่ดังกล่าว เดิมยังสามารถใช้ต่อได้จนถึง 30 กันยายน 2024
- ตั้งแต่ 30 กันยายน 2024 เดิมมีแผนจะปิดการเข้าถึง LSA สำหรับบัญชี Google Workspace ทั้งหมด
- CalDAV, CardDAV, IMAP, POP และ Google Sync จะไม่ทำงานอีกต่อไปเมื่อเข้าสู่ระบบด้วยรหัสผ่านอย่างเดียว
- หากต้องการใช้งานต่อ ต้องเข้าสู่ระบบด้วย OAuth ซึ่งเป็นวิธีเข้าถึงที่ปลอดภัยกว่า
- หลังจากนั้นกำหนดการถูกปรับหลายครั้ง
- อัปเดตวันที่ 15 ตุลาคม 2024 ระบุว่าการ rollout ถูกหยุดจนถึงสิ้นปี และเปลี่ยนเป็นจะกลับมาเริ่มใหม่ในเดือนมกราคม 2025
- อัปเดตวันที่ 27 มกราคม 2025 ระบุว่าการ rollout กลับมาเริ่มอีกครั้ง และมีแผนปิดใช้งานขั้นสุดท้ายในเดือนมีนาคม 2025
- อัปเดตวันที่ 12 กุมภาพันธ์ 2025 เปลี่ยนวันสิ้นสุดการรองรับ LSA เป็น 14 มีนาคม 2025
- อัปเดตวันที่ 29 เมษายน 2025 ระบุว่า LSA จะไม่รองรับอีกต่อไปตั้งแต่ 1 พฤษภาคม 2025
จุดที่องค์กรที่ใช้ Google Sync ควรตรวจสอบ
- การเปลี่ยนแปลงครั้งนี้รวมถึง การยุติ Google Sync ด้วย
- เดิมกำหนดการยุติ Google Sync มีดังนี้
- ตั้งแต่ 15 มิถุนายน 2024 ผู้ใช้ใหม่จะไม่สามารถเชื่อมต่อกับ Google Workspace ผ่าน Google Sync ได้
- ตั้งแต่ 30 กันยายน 2024 ผู้ใช้ Google Sync เดิมก็จะไม่สามารถเชื่อมต่อกับ Google Workspace ได้เช่นกัน
- สามารถตรวจสอบการใช้งาน Google Sync ภายในองค์กรได้จาก Admin Console
- เส้นทาง: Devices > Mobile & Endpoints > Devices
- ตัวกรอง: Type: Google Sync
ผลกระทบต่อผู้ดูแลระบบและการตั้งค่า MDM
- ผู้ดูแลระบบควรแนะนำให้ผู้ใช้ปลายทางเปลี่ยนไปใช้ วิธีเข้าถึงแบบ OAuth เพื่อให้ยังใช้งานแอปกับบัญชี Google Workspace ได้ต่อไป
- ข้อมูลผู้ใช้ที่ได้รับผลกระทบจะถูกส่งให้กับองค์กรทางอีเมลในช่วงหลายเดือนข้างหน้า
- องค์กรที่เคยตั้งค่าโปรไฟล์ IMAP, CalDAV, CardDAV, POP, Exchange ActiveSync (Google Sync) ผ่านผู้ให้บริการ MDM ก็ได้รับผลกระทบเช่นกัน
- ตั้งแต่ 15 มิถุนายน 2024 การ push ผ่าน MDM สำหรับ IMAP, CalDAV, CardDAV, SMTP, POP และ Exchange ActiveSync (Google Sync) ที่อิงรหัสผ่านจะไม่ทำงานสำหรับลูกค้าที่พยายามเชื่อมต่อกับ LSA เป็นครั้งแรก
- หากใช้ Google Endpoint Management จะไม่สามารถเปิดการตั้งค่า Custom Push Configuration สำหรับ CalDAV และ CardDAV ได้
- ตั้งแต่ 30 กันยายน 2024 การ push แบบใช้รหัสผ่านสำหรับ IMAP, CalDAV, CardDAV, SMTP, POP สำหรับผู้ใช้เดิมจะไม่ทำงาน
- ผู้ดูแลระบบต้องใช้ผู้ให้บริการ MDM เพื่อ push Google Account ซึ่งเป็นวิธีเพิ่มบัญชี Google ใหม่บนอุปกรณ์ iOS ด้วย OAuth
- การ push แบบใช้รหัสผ่านของ Exchange ActiveSync (Google Sync) ก็จะไม่ทำงานสำหรับผู้ใช้เดิมเช่นกัน
- การตั้งค่า “Custom push configuration-CalDAV” และ “Customer push configuration-CardDAV” ใน Google Endpoint Management จะหมดผล
วิธีเปลี่ยนผ่านตามอุปกรณ์ แอป และนักพัฒนา
- หากสแกนเนอร์หรืออุปกรณ์อื่นส่งอีเมลผ่าน SMTP หรือ LSA ต้องทำอย่างใดอย่างหนึ่งต่อไปนี้
- ตั้งค่าให้ใช้ OAuth
- ใช้วิธีทางเลือกอื่น
- ตั้งค่า App Passwords สำหรับอุปกรณ์นั้น
- แอปที่เข้าถึงบัญชี Google ด้วยเพียงชื่อผู้ใช้และรหัสผ่านจำเป็นต้องดำเนินการย้ายระบบ
- หากไม่ดำเนินการภายในวันยุติ จะมีข้อความผิดพลาดว่าชุดชื่อผู้ใช้-รหัสผ่านไม่ถูกต้องและจะไม่สามารถเข้าสู่ระบบได้
- แนวทางสำหรับแต่ละแอปอีเมล
- Outlook 2016 หรือเวอร์ชันเก่ากว่าต้องย้ายไปใช้ Microsoft 365, Outlook for Windows หรือ Outlook for Mac ซึ่งรองรับการเข้าถึงแบบ OAuth
- อีกทางเลือกหนึ่งคือใช้ Google Workspace Sync for Microsoft Outlook
- Thunderbird หรือไคลเอนต์อีเมลอื่นต้องเพิ่มบัญชี Google ใหม่อีกครั้งและตั้งค่า IMAP ให้ใช้ OAuth
- หากใช้แอป Mail บน iOS หรือ macOS หรือ Outlook for Mac โดยเข้าสู่ระบบด้วยรหัสผ่านอย่างเดียว ต้องลบบัญชีแล้วเพิ่มใหม่และเลือก “Sign in with Google”
- แอปปฏิทินและรายชื่อติดต่อก็ต้องเปลี่ยนไปใช้วิธีที่รองรับ OAuth เช่นกัน
- แอปปฏิทินที่ใช้ CalDAV แบบอิงรหัสผ่านต้องเปลี่ยนไปใช้วิธีที่รองรับ OAuth และ Google แนะนำแอป Google Calendar
- หากใช้แอปปฏิทินบน iOS หรือ macOS โดยเข้าสู่ระบบด้วยรหัสผ่านอย่างเดียว ต้องลบบัญชีแล้วเพิ่มใหม่และเลือก “Sign in with Google”
- หากซิงก์รายชื่อติดต่อบน iOS หรือ macOS ผ่าน CardDAV และเข้าสู่ระบบด้วยรหัสผ่านอย่างเดียว ต้องลบบัญชีแล้วเพิ่มใหม่และเลือก “Sign in with Google”
- หากใช้ CardDAV กับรหัสผ่านอย่างเดียวบนแพลตฟอร์มหรือแอปอื่น ต้องเปลี่ยนไปใช้วิธีที่รองรับ OAuth
- แอปที่ไม่รองรับ OAuth ต้องเปลี่ยนไปใช้แอปที่มี OAuth หรือสร้าง App Passwords เพื่อเข้าถึง
- นักพัฒนาต้องอัปเดตวิธีเชื่อมต่อของแอปเป็น OAuth 2.0 เพื่อคงความเข้ากันได้กับบัญชี Google Workspace
บัญชี Google ส่วนบุคคลและขอบเขตการบังคับใช้
- ผู้ใช้บัญชี Google ส่วนบุคคลจะเห็นการนำสวิตช์เปิด/ปิด IMAP ออกจากการตั้งค่า Gmail
- การเข้าถึง IMAP ของบัญชีส่วนบุคคลถูกเปิดใช้งานผ่าน OAuth อยู่แล้วเสมอ และการเชื่อมต่อปัจจุบันจะไม่ได้รับผลกระทบ
- ผู้ใช้บัญชี Google ส่วนบุคคลไม่จำเป็นต้องดำเนินการเพิ่มเติม
- การเปลี่ยนแปลงนี้มีผลกับ ลูกค้า Google Workspace ทั้งหมด
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
อ่านบทความนี้แล้วใจหายวาบไปชั่วขณะ — เพราะมีสคริปต์และเครื่องมือหลายตัวที่ผูกกับ Gmail อยู่
แต่ดูเหมือนจะยังไม่เป็นไร รหัสผ่านแอป ยังน่าจะทำงานต่อได้ และการเปลี่ยนแปลงครั้งนี้น่าจะเป็นการยกเลิกรองรับ Less Secure Apps ที่ใช้ชื่อผู้ใช้/รหัสผ่านปกติของบัญชีมากกว่า
แค่คิดว่า automation จำนวนมากแค่ไหนจะพัง ถ้า Google ตัดทุกอย่างที่ไม่ใช่ OAuth ออกไปจริง ๆ ก็ขนลุกแล้ว
ผมไม่ชอบความซับซ้อนของ OAuth และชอบวิธีที่เอกสารของโมดูล Perl นี้อธิบายโครงสร้างของมัน ดูชัดเลยว่าคนเขียนคงหงุดหงิดเหมือนผม: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
เคยเจอปัญหาคล้ายกัน และใน Workspace หนึ่งรหัสผ่านแอปถูกบล็อกไว้ ใช้สคริปต์ Python เล็ก ๆ เพื่อรับ โทเคน OAuth แล้วใช้มันเหมือนรหัสผ่านได้: https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
ดูตัวอย่างได้ที่ https://github.com/lefcha/imapfilter/issues/186
ตอนนี้ต้องเปิด สวิตช์ LSA ไว้ตลอด เพื่อให้บัญชี Gmail หลักส่ง SMTP โดยใช้ข้อมูลรับรองของบัญชี Gmail อื่น ๆ ได้ ไม่เข้าใจว่าทำไมในสายตาของบัญชี Gmail อื่น Gmail ถึงเป็น LSA
เป็นตัวพิมพ์เล็ก 16 ตัว แบ่งด้วยช่องว่างทุก 4 ตัว ไม่มีตัวเลขหรืออักขระพิเศษ
Keepass ประเมินว่าเมื่อเอาช่องว่างออกแล้ว มันเป็นรหัสผ่านอ่อนที่มี เอนโทรปี 65 บิต
ไม่รู้ว่านี่เป็นการปรับปรุงตรงไหน
ถ้าเปลี่ยนไปใช้ OAuth ไม่ได้ ลองใช้พร็อกซีของผม จะทำให้ไคลเอนต์ IMAP/POP/SMTP ที่ไม่รองรับ OAuth 2.0 โดยตรงยังใช้งานกับผู้ให้บริการอีเมลแบบ “สมัยใหม่” ได้: https://github.com/simonrob/email-oauth2-proxy
ไคลเอนต์ไม่จำเป็นต้องรู้อะไรเกี่ยวกับ OAuth เลย
ถ้าเปลี่ยนไปใช้ OAuth ไม่ได้ ก็สร้างรหัสผ่านแอปแล้วใช้เป็นรหัสผ่าน IMAP ตามปกติต่อไปได้
เพราะ IMAP, SMTP, POP ให้สิทธิ์เข้าถึงบัญชี Google และชีวิตโดยรวมค่อนข้างมาก แต่ไม่มีวิธีทำ การยืนยันแบบ 2 ขั้นตอน และไม่มีการตรวจสอบป้องกันบอต
ทำให้การโจมตีแบบลองข้อมูลรับรองเป็นเรื่องง่ายมาก และในระดับของ Google การโจมตีแบบนั้นอาจทำลายชีวิตคนจำนวนมากได้
นี่เป็นการเปลี่ยนแปลงที่ดี และควรทำตั้งแต่หลายปีก่อนแล้ว จริง ๆ ก็ทำไปบ้างแล้วในระดับหนึ่ง เช่น ปิดการเข้าถึง IMAP/POP/SMTP เป็นค่าเริ่มต้น ซึ่งช่วยปกป้องผู้ใช้ส่วนใหญ่ได้ กรณีนี้เป็นมาตรการสำหรับผู้ใช้ที่เหลือ
ใน Dovecot แค่เลือกโมดูลยืนยันตัวตนที่ชอบ แล้วปรับให้อ่านรหัสผ่านที่ป้อนเป็น
pwd+otp codeถ้าผู้ใช้เปิดการยืนยันแบบ 2 ขั้นตอนไว้ ก็อ่าน 6 ตัวท้ายแล้วเทียบกับ TOTPถ้าตรงกันก็อนุญาต IP นั้นเป็นเวลา x นาที หรือใช้นโยบายอะไรก็ได้ตามต้องการ
มันทำงานได้ดีอย่างไม่น่าเชื่อ
ที่อยู่นั้นไม่ใช่ Gmail และเป็นบริการที่ยังอนุญาต IMAP/POP อยู่ ไม่ใช่ยาครอบจักรวาล แต่สำหรับบาง use case ก็อาจเป็นทางอ้อมที่ยอมรับได้
นี่คือการพยายามดึงผู้ใช้ออกจากแอปเมลเนทีฟดี ๆ แล้วต้อนให้ไปใช้แอปของ Google เอง
หากไม่มี gmail.app หรือ Google Sync ที่กำลังจะถูกยกเลิก ก็จะไม่ได้รับ การแจ้งเตือนอีเมลแบบเรียลไทม์ ไม่ชอบเลย แม้จะจ่ายค่า Workspace อยู่ก็ตามก็ยังไม่ชอบ บนเดสก์ท็อป Mimestream ยังใช้งานได้อยู่ แต่รู้สึกว่าอีกไม่นานก็คงถูกเล็งเหมือนกัน
JMAP เป็นโปรโตคอลมาตรฐานที่ดี แต่มีอัตราการใช้งานต่ำอย่างไม่น่าเชื่อเพราะปัญหาไก่กับไข่ระหว่างผู้ให้บริการเมลกับแอปเมล ถ้า Gmail รองรับ JMAP ก็จะช่วยผลักดันให้ผู้พัฒนาทั่วไปเพิ่มการรองรับได้ JMAP รองรับการแจ้งเตือนและฟีเจอร์อื่น ๆ ด้วย
OAuth สำหรับอีเมลอยู่ใน RFC หลายฉบับที่เกี่ยวกับการยืนยันตัวตนอีเมล และมีมาหลายปีแล้ว
Thunderbird กับแอปมือถือหลายตัวรองรับ Gmail ได้ดีผ่าน OAuth ปัญหาที่ใหญ่กว่าคือแอปเดสก์ท็อปจำนวนมากดูเหมือนหยุดทำการเปลี่ยนแปลงเกี่ยวกับ IMAP และ SMTP มาตั้งแต่ราว 10 ปีก่อน
ถ้าเป็นแอปอีเมลที่ไม่ได้รับการดูแลต่อแล้ว ก็ใช้ รหัสผ่านเฉพาะแอป ตามที่ Google แนะนำในบทความที่ลิงก์ไว้ได้ สิ่งเหล่านั้นจะยังใช้งานต่อไปได้ สิ่งที่จะหายไปคือวิธีใช้ชื่อผู้ใช้/รหัสผ่านของบัญชีหลักแบบฮาร์ดโค้ด
สำหรับผู้ใช้ Office 2016 คงเป็นปัญหาใหญ่ เพราะวันที่ 30 กันยายนยังเร็วกว่าวันสิ้นสุดการรองรับ Outlook อยู่ประมาณ 9 เดือน แต่สำหรับผู้ใช้ส่วนใหญ่ น่าจะเป็นการแก้ไขที่ค่อนข้างง่าย
อีเมลเป็นการสื่อสารแบบอะซิงโครนัส ดังนั้นต่อให้รู้หลังจากข้อความมาถึง 10 นาทีก็ควรไม่มีปัญหา ถ้าเป็นเมลที่กำลังรออยู่ ยังไงก็จะกดรีเฟรชรัว ๆ จนกว่าจะมาถึงอยู่แล้ว
ถ้าด่วนกว่านั้นก็ส่งข้อความมา อย่าโทรมาเลย ไม่ชอบโทรศัพท์
มีคำอธิบายว่า “รหัสผ่านสำหรับแอปคือรหัส 16 หลักที่ให้สิทธิ์แอปหรืออุปกรณ์ที่ปลอดภัยน้อยกว่าเข้าถึงบัญชี Google ของคุณ และใช้ได้เฉพาะกับบัญชีที่เปิดการยืนยันแบบ 2 ขั้นตอนเท่านั้น”: https://support.google.com/mail/answer/185833
ตลกไหมที่ “แอปหรืออุปกรณ์ที่ปลอดภัยน้อยกว่า” หากใช้แค่กลไกฝั่งเซิร์ฟเวอร์ที่ Google น่าจะสนับสนุนมาตั้งนานแล้ว ก็แทบจะเทียบเท่ากับแอปที่รองรับ OAuth ในแง่ความปลอดภัยได้เลย ในเชิงเทคนิคดูเหมือนไม่ใช่ความสามารถของตัวแอปด้วยซ้ำ
แน่นอน อาจบอกได้ว่าการทำให้เรียบง่ายนั้นสมเหตุสมผล เพราะถ้าเรียกว่า “แอปที่มีเวิร์กโฟลว์ปลอดภัยแต่ใช้งานไม่สะดวก” ก็คงสื่อสารได้แย่กว่า ปัญหาใหญ่กว่าคือ Google มักตีความข้อกังวลด้านความปลอดภัยในทางที่เอื้อต่อวาระของตัวเองเสมอ และส่วนนี้ก็ไม่ใช่ข้อยกเว้น
ตอนนี้แค่บังคับใช้กับแอปที่ไม่สามารถอัปเดตให้รองรับ OAuth ได้เท่านั้น
รหัสผ่านสำหรับแอปในเชิงฟังก์ชันแทบจะเป็นแบบอนุญาตทั้งหมดหรือบล็อกทั้งหมด แต่ใน OAuth สามารถกำหนดสิทธิ์อย่างการอ่าน การแก้ไข การเปลี่ยนการตั้งค่าได้
สิ่งที่น่ารำคาญที่สุดเกี่ยวกับ Google OAuth2 บน Android คือ ถ้าจะล็อกอินด้วยบัญชี Google ในไคลเอนต์อีเมลหรือปฏิทิน โทรศัพท์ทั้งเครื่องต้องถูกเชื่อมกับบัญชี Google นั้น
นอกจากนี้บัญชี Google นั้นยังได้สิทธิ์ด้านนโยบายอุปกรณ์ด้วย ในความเห็นผม นี่ไม่สมเหตุสมผลเลย
การใช้ OAuth2 ใน WebView ภายในแอปก็ถูก Google จำกัดบน Android ได้ง่าย จึงเลี่ยงได้ยาก
น่าเสียดายที่ไคลเอนต์อีเมลที่ไว้ใจได้มีไม่มาก หลายตัวส่งข้อมูลรับรองไปยังเซิร์ฟเวอร์ระยะไกล
แก้ไข: k9 รองรับ OAuth สำหรับ IMAP อยู่แล้ว
https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
ถ้อยคำค่อนข้างกำกวมเล็กน้อย แต่ดูเหมือนว่า รหัสผ่านเฉพาะแอป จะยังใช้งานต่อไปได้
ในข้อความที่ยกมา ระบุว่าสแกนเนอร์และอุปกรณ์ที่ส่งอีเมลผ่าน SMTP หรือ LSA ต้องตั้งค่าให้ใช้ OAuth ใช้วิธีอื่น หรือกำหนดรหัสผ่านสำหรับแอปของอุปกรณ์
และยังระบุว่าแอปที่ไม่รองรับ OAuth ให้เปลี่ยนไปใช้แอปที่รองรับ OAuth หรือสร้างรหัสผ่านสำหรับแอปเพื่อเข้าถึง
ดังนั้นเมื่อวานผมจึงถาม Google Workspace Support โดยตรง และคำตอบคือ “รหัสผ่านสำหรับแอปรองรับ IMAP, POP และการกำหนดค่า SMTP ทั้งหมด”
ประโยคที่สองเป็นการผลักดันให้ใช้ OAuth ต่อไป ผมก็อยากทำแบบนั้นเหมือนกัน แต่ค่าใช้จ่ายในการตรวจสอบความปลอดภัยซ้ำ ๆ เป็นสิ่งที่แอป SaaS เล็ก ๆ อย่างเรารับไม่ไหว โชคดีที่เรายังจะใช้รหัสผ่านสำหรับแอปต่อไปได้
เรื่องนี้เกี่ยวกับ บัญชี Workspace และเป็นการเปลี่ยนแปลงที่มีผลกับบัญชี Gmail ทั่วไปไปแล้วเมื่อหลายปีก่อน
ผมยังเข้าถึงบัญชี Gmail ส่วนตัวจาก Mail.app บน iPhone ผ่านตัวเลือก Microsoft Exchange อยู่ และได้รับการแจ้งเตือนแบบพุชด้วยวิธีนี้โดยไม่ต้องผูกกับ Fetch
เหตุผลที่ยังใช้งานได้คือการเชื่อมต่อ Google Sync ที่สร้างไว้กับบัญชีส่วนตัวก่อนวันที่ยุติบริการเมื่อราว 10 ปีก่อนยังคงอยู่ และถูกยอมรับเหมือนเป็น “สิทธิ์เดิม”
ดังนั้นถ้าต้องการให้ใช้งานได้ ก็แค่แก้ GUID ของ Exchange บน iPhone ให้เป็น GUID ของโทรศัพท์เครื่องที่เคยล็อกอิน Google Sync ก่อนการยุติการล็อกอินใหม่
โชคดีที่สามารถเปลี่ยน GUID นี้ได้โดยสร้างแบ็กอัป iPhone แก้ไฟล์ plist ในแบ็กอัป แล้วกู้คืนกลับไป
ตอนนี้ผมก็ยังใช้ Mail.app และการแจ้งเตือนแบบพุชกับบัญชี Gmail ส่วนตัวบน iPhone 14 Pro อยู่
จากประกาศ ผมเข้าใจว่ารหัสผ่านสำหรับแอปจะยังคงอยู่ไปอีกระยะหนึ่ง แต่ถ้าวันหนึ่ง Google ยกเลิกรหัสผ่านสำหรับแอปด้วย การใช้ไคลเอนต์บุคคลที่สามกับ GMail จะถูกจำกัดอย่างมาก เพราะโครงสร้างที่บังคับให้ไคลเอนต์ OAuth ต้องเข้ารับ การประเมินความปลอดภัย ด้วยค่าใช้จ่ายของตัวเอง
อีเมลยังเป็นหนึ่งใน “โปรโตคอลส่งข้อความแบบเปิด” กลุ่มสุดท้ายที่ยังใช้กันแพร่หลาย และผู้ใช้ยังเลือกไคลเอนต์ได้ ถ้าทิศทางนี้เกิดขึ้นก็คงเป็นพัฒนาการที่น่าเศร้า
ที่บริษัทกำลังจัดการการย้ายไปใช้ OAuth ของ Microsoft อยู่ และมันปวดหัวทีเดียว
ส่วนหนึ่งของปัญหาคือมันไม่โปร่งใสเอามาก ๆ พอส่งโทเคนไป เซิร์ฟเวอร์ก็ตอบกลับมาแค่ว่า “ไม่” โดยไม่มีคำอธิบายเพิ่มเติม
ผมใช้เวลาหลายวันเพื่อหาว่าทำไม flow แบบ Client Credentials ถึงใช้ไม่ได้ และสุดท้ายก็ไปเจอคำตอบลึก ๆ ในฟอรัมช่วยเหลือว่า “อ้อ client credentials flow ยังไม่รองรับ” ตอนนี้รองรับกับ IMAP/POP แล้ว แต่เท่าที่จำได้ SMTP ยังน่าจะยังไม่รองรับ อย่างไรก็ตาม SMTP ยังไม่ได้บังคับใช้ OAuth
ต่อมาคือการหาว่า scope ที่ถูกต้องคืออะไร ซึ่งตอนนั้นเอกสารก็ไม่ได้ดีนัก ข้อความผิดพลาดจากเซิร์ฟเวอร์ก็ไม่ช่วยอะไรเลย
เซิร์ฟเวอร์เมลของ Google ดีกว่านี้ไหม?
น่าเสียดายที่เซิร์ฟเวอร์ไม่มีช่องว่างให้ให้ข้อมูลที่ “เป็นประโยชน์” แก่ไคลเอนต์ที่ยังไม่ได้รับการยืนยันตัวตน