ทำไมคุณควรเลิกใช้ประเภทการอนุญาต Resource Owner Password Credentials (ROPC)

บทนำ#

ประเภทการอนุญาต Resource Owner Password Credentials (ROPC) หรือที่เรียกว่า password grant type เป็นกระบวนการ OAuth 2.0 ที่อนุญาตให้แอปพลิเคชันแลกเปลี่ยนชื่อผู้ใช้และรหัสผ่านของผู้ใช้เพื่อให้ได้โทเค็นการเข้าถึง ครั้งแรกที่ถูกแนะนำในข้อกำหนด OAuth 2.0 เพื่อสนับสนุนแอปพลิเคชันเก่าเช่นการตรวจสอบ HTTP พื้นฐานหรือแอปพลิเคชันที่ไม่สามารถใช้กระบวนการที่ปลอดภัยกว่าในรูปแบบโทเค็น OAuth ได้

อย่างไรก็ตาม ประเภทการอนุญาต ROPC มีความเสี่ยงด้านความปลอดภัยหลายประการและได้รับการระบุว่าเป็น ห้ามใช้เด็ดขาด ใน แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัยของ OAuth 2.0

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

ประเภทการอนุญาต ROPC กับกระบวนการโค้ดการอนุญาต#

การทำงานของประเภทการอนุญาต ROPC#

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

การทำงานของกระบวนการโค้ดการอนุญาต#

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

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

ความเสี่ยงด้านความปลอดภัยของประเภทการอนุญาต ROPC#

1. การเปิดเผยข้อมูลประจำตัวของผู้ใช้#

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

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

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

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

ลองคิดดูว่าถ้าคุณมีแอปพลิเคชันหลายแอปที่ใช้ประเภทการอนุญาต ROPC ความเสี่ยงที่เป็นไปได้ของการเปิดเผยข้อมูลประจำตัวก็จะมากขึ้น

2. ROPC ไม่รองรับการยินยอมของผู้ใช้#

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

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

3. ROPC ไม่รองรับการยืนยันตัวตนหลายขั้นตอน#

การยืนยันตัวตนหลายขั้นตอน (MFA) เป็นการดำเนินการด้านความปลอดภัยที่ต้องการให้ผู้ใช้ให้การยืนยันสองปัจจัยหรือมากกว่านั้นเพื่อเข้าถึงทรัพยากรของพวกเขา มันเพิ่มชั้นความปลอดภัยพิเศษให้กับกระบวนการยืนยันตัวตน ประเภทการอนุญาต ROPC ไม่สนับสนุน MFA แต่มันจำกัดกระบวนการยืนยันตัวตนให้อยู่ที่ระดับเดียว และคำขอโทเค็นเพียงถูกตีความจากข้อมูลประจำตัวของผู้ใช้เท่านั้น เป็นไปไม่ได้ที่จะใช้กลไกการยืนยันแบบท้าทายเช่น SMS OTP, email OTP, หรือ WebAuthn กับประเภทการอนุญาต ROPC

ROPC ไม่เข้ากันกับแอปพลิเคชันที่ทันสมัย#

ประเภทการอนุญาต ROPC ถูกออกแบบมาเพื่อสนับสนุนแอปพลิเคชันที่ล้าสมัย ซึ่งไม่สามารถสนับสนุนระบบ IAM ที่ทันสมัยซึ่งใช้ Single Sign-On (SSO) หรือเอกลักษณ์ที่เป็นพันธมิตรได้

1. ROPC ไม่เข้ากันกับ SSO#

Single Sign-On (SSO) เป็นสถาปัตยกรรมการยืนยันตัวตนที่ทันสมัยที่อนุญาตให้ผู้ใช้ล็อกอินครั้งเดียวและเข้าถึงหลายแอปพลิเคชันได้อย่างง่ายดาย

IdP สาธารณเป็นบทบาทสำคัญในสถาปัตยกรรม SSO มันจัดการการยืนยันตัวตนของผู้ใช้และออกโทเค็นให้แอปพลิเคชันไคลเอนต์ แอปพลิเคชันไคลเอนต์ไม่จำเป็นต้องรวบรวมข้อมูลประจำตัวของผู้ใช้โดยตรง และข้อมูลประจำตัวของผู้ใช้จะถูกเก็บรักษาเป็นความลับภายใน IdP

ประเภทการอนุญาต ROPC ไม่สนับสนุน SSO มันต้องการให้แอปพลิเคชันไคลเอนต์รวบรวมข้อมูลประจำตัวของผู้ใช้โดยตรง ซึ่งเป็นการทำลายสถาปัตยกรรม SSO มันไม่เข้ากันกับระบบ SSO ที่ทันสมัยเช่น OpenID Connect (OIDC) หรือ SAML

2. ROPC ไม่เข้ากันกับเอกลักษณ์ที่เป็นพันธมิตร#

เช่นเดียวกับสถาปัตยกรรม SSO เอกลักษณ์ที่เป็นพันธมิตรอนุญาตให้ผู้ใช้ใช้เอกลักษณ์ที่มีอยู่ของพวกเขาเพื่อเข้าถึงแอปพลิเคชันที่เป็นบุคคลที่สามหลายแอป ผู้ใช้อาจเชื่อมโยงบัญชีโซเชียลหลายบัญชีเช่น Google, Facebook, หรือ Twitter กับ IdP สาธารณ และใช้บัญชีเหล่านี้ในการยืนยันตัวตนกับแอปพลิเคชันไคลเอนต์ เอกลักษณ์ที่เป็นพันธมิตรทั้งหมดจะถูกจัดการโดย IdP และแอปพลิเคชันไคลเอนต์ไม่ทราบรายละเอียดการยืนยันตัวตนของผู้ใช้ภายใต้ขอบเขต

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

บทสรุป#

ประเภทการอนุญาต Resource Owner Password Credentials (ROPC) เป็นกระบวนการ OAuth 2.0 เก่าที่มีความเสี่ยงด้านความปลอดภัยอย่างมากและควรถูกยกเลิก มันเปิดเผยข้อมูลประจำตัวของผู้ใช้ต่อแอปพลิเคชันไคลเอนต์ ไม่สนับสนุนกลไกความปลอดภัยที่ทันสมัยเช่น MFA หรือ SSO เราขอแนะนำอย่างยิ่งให้หลีกเลี่ยงการใช้ประเภทการอนุญาต ROPC สำหรับแอปพลิเคชันของคุณ ถ้าคุณมีระบบยืนยันตัวตนแบบเก่าที่ต้องพึ่งพาประเภทการอนุญาต ROPC ควรพิจารณาเปลี่ยนไปใช้กระบวนการ OAuth 2.0 ที่ปลอดภัยมากขึ้น เช่น กระบวนการโค้ดการอนุญาตหรือประเภทการอนุญาตตามข้อมูลระบุตัวตนของลูกค้า

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