ไทย

oauth
security
oidc
authentication

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

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

Simeng

Developer

4/24/2024

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ

เริ่มต้นใช้งาน

บทนำ

ประเภทการอนุญาต 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 ที่ปลอดภัยมากขึ้น เราพร้อมช่วยคุณสร้างแอปพลิเคชันที่ปลอดภัยและทันสมัย

บทนำ#

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

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

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

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

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

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

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

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

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

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

บทสรุป#

บทนำ#

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

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

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

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

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

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

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

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

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

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

บทสรุป#

บทนำ

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

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

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

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

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

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

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

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

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

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

บทสรุป

บทนำ

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

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

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

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

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

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

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

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

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

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

บทสรุป