ขั้นตอน OAuth 2.0 ที่เหมาะสมสำหรับแอปบนอุปกรณ์เคลื่อนที่คืออะไร

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

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

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

ชี้แจง: Mobile App = Native App

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับแอป OAuth2

ไม่ว่าคุณจะเลือกแนวทางใด (มีข้อยกเว้นบางประการที่ต้องพิจารณา) คุณควรใส่ใจกับแนวทางปฏิบัติที่ดีที่สุดตามที่อธิบายไว้ที่นี่สำหรับ Native Apps ที่ใช้ OAuth2: https://tools.ietf.org/html/rfc8252

พิจารณาตัวเลือกต่อไปนี้

โดยปริยาย

ฉันควรใช้นัยหรือไม่?

อ้างจากหัวข้อ 8.2 https://tools.ietf.org/html/rfc8252#section-8.2

ขั้นตอนการอนุญาตโดยปริยาย OAuth 2.0 (กำหนดไว้ในส่วน 4.2 ของ OAuth 2.0 [RFC6749]) โดยทั่วไปจะทำงานร่วมกับการปฏิบัติตามคำขอการอนุญาตในเบราว์เซอร์และรับการตอบสนองการอนุญาตผ่านการสื่อสารระหว่างแอปที่ใช้ URI
อย่างไรก็ตามเนื่องจาก PKCE [RFC7636] ไม่สามารถป้องกันโฟลว์โดยนัยได้ (ซึ่งจำเป็นในส่วน 8.1) จึงไม่แนะนำให้ใช้ Implicit Flow กับแอปเนทีฟมาพร้อมเครื่อง

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

รหัสการอนุญาต

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

ข้อความที่ตัดตอนมาด้านล่างจาก: https://dev.fitbit.com/docs/oauth2/

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

หมายเหตุ: อย่าใส่รหัสลับไคลเอ็นต์ของคุณในโค้ดแบบกระจายเช่นแอพที่ดาวน์โหลดผ่านแอพสโตร์หรือ JavaScript ฝั่งไคลเอ็นต์

แอปพลิเคชันที่ไม่มีบริการเว็บควรใช้ขั้นตอนการให้โดยนัย

สรุป

การตัดสินใจขั้นสุดท้ายควรคำนึงถึงประสบการณ์การใช้งานที่คุณต้องการ แต่ยังรวมถึงความกระหายที่จะเสี่ยงหลังจากทำการประเมินความเสี่ยงที่เหมาะสมของแนวทางสั้น ๆ ของคุณและเข้าใจผลกระทบที่ดีขึ้น

การอ่านที่ยอดเยี่ยมอยู่ที่นี่https://auth0.com/blog/oauth-2-best-practices-for-native-apps/

อีกอันหนึ่งคือhttps://www.oauth.com/oauth2-servers/oauth-native-apps/ซึ่งระบุว่า

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

การพิจารณา PKCE

คุณควรพิจารณา PKCE ซึ่งอธิบายไว้ที่นี่ https://www.oauth.com/oauth2-servers/pkce/

โดยเฉพาะอย่างยิ่งหากคุณกำลังติดตั้งเซิร์ฟเวอร์การอนุญาตด้วยเช่นกันhttps://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ระบุว่าคุณควร

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

การพิจารณาการดูเว็บ

มีตัวอย่างมากมายในการใช้ Web Views เช่น User-agent แบบฝัง แต่ควรหลีกเลี่ยงวิธีนี้ (โดยเฉพาะเมื่อแอปไม่ใช่บุคคลที่หนึ่ง) และในบางกรณีอาจส่งผลให้คุณถูกห้ามไม่ให้ใช้ API เป็นข้อความที่ตัดตอนมา ด้านล่างจากที่นี่แสดงให้เห็น

ความพยายามใด ๆ ในการฝังหน้าการตรวจสอบสิทธิ์ OAuth 2.0 จะส่งผลให้แอปพลิเคชันของคุณถูกแบนจาก Fitbit API

เพื่อการพิจารณาด้านความปลอดภัยหน้าการให้สิทธิ์ OAuth 2.0 ต้องแสดงในมุมมองเบราว์เซอร์เฉพาะ ผู้ใช้ Fitbit สามารถยืนยันได้ก็ต่อเมื่อตรวจสอบสิทธิ์กับเว็บไซต์ Fitbit.com ของแท้หากพวกเขามีเครื่องมือที่เบราว์เซอร์จัดเตรียมไว้ให้เช่นแถบ URL และข้อมูลใบรับรอง Transport Layer Security (TLS)

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

แอปพลิเคชัน iOS อาจใช้คลาส SFSafariViewController แทนการเปลี่ยนแอปเป็น Safari ห้ามใช้คลาส WKWebView หรือ UIWebView

แอปพลิเคชัน Android อาจใช้ Chrome Custom Tabs แทนการเปลี่ยนแอปไปใช้เบราว์เซอร์เริ่มต้น ห้ามใช้ WebView

หากต้องการชี้แจงเพิ่มเติมนี่คือคำพูดจากส่วนนี้ของร่างก่อนหน้าของลิงก์แนวทางปฏิบัติที่ดีที่สุดที่ให้ไว้ด้านบน

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

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

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

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

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

เนื่องจากข้างต้นไม่แนะนำให้ใช้ User-agent แบบฝังยกเว้นในกรณีที่แอปของบุคคลที่หนึ่งที่เชื่อถือได้ทำหน้าที่เป็นตัวแทนผู้ใช้ภายนอกสำหรับแอปอื่น ๆ หรือให้การลงชื่อเพียงครั้งเดียวสำหรับแอปของบุคคลที่หนึ่งหลายแอป

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

นอกจากนี้ยังมีประเด็นที่น่าสนใจบางประการที่นี่: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- ก

น่าเสียดายที่ฉันไม่คิดว่าจะมีคำตอบที่ชัดเจนสำหรับคำถามนี้ อย่างไรก็ตามนี่คือตัวเลือกที่ฉันระบุ:

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

  • การใช้งานหรือนโยบายความปลอดภัยห้ามไม่ให้ใส่รหัสผ่านโดยตรงที่แอป
  • กระบวนการรับรองความถูกต้องถูกมอบหมายบนผู้ให้บริการข้อมูลประจำตัวภายนอกและต้องดำเนินการผ่านโฟลว์ที่ใช้การเปลี่ยนเส้นทาง HTTP (เช่น OpenID, SAMLP หรือ WS-Federation)

• หากการใช้งานของการไหลของเบราว์เซอร์จะต้องจากนั้นใช้รหัสการให้สิทธิ์การไหล คำจำกัดความของสิ่งredirect_uriนี้เป็นความท้าทายที่สำคัญซึ่งมีตัวเลือกดังต่อไปนี้:

  • ใช้เทคนิคที่อธิบายไว้ในhttps://developers.google.com/accounts/docs/OAuth2InstalledAppโดยที่พิเศษredirect_uri(เช่นurn:ietf:wg:oauth:2.0:oob) ส่งสัญญาณไปยังจุดสิ้นสุดการให้สิทธิ์เพื่อแสดงรหัสการให้สิทธิ์แทนการเปลี่ยนเส้นทางกลับไปที่แอปไคลเอ็นต์ ผู้ใช้สามารถคัดลอกโค้ดนี้ด้วยตนเองหรือแอปสามารถลองรับจากชื่อเอกสาร HTML
  • ใช้ localhostเซิร์ฟเวอร์ที่อุปกรณ์ (การจัดการพอร์ตอาจไม่ใช่เรื่องง่าย)
  • ใช้โครงร่าง URI ที่กำหนดเอง (เช่น myapp://... ) ซึ่งเมื่อ dereferenced ทริกเกอร์ "ตัวจัดการ" ที่ลงทะเบียน (รายละเอียดขึ้นอยู่กับแพลตฟอร์มมือถือ)
  • หากมีให้ใช้ "มุมมองเว็บ" แบบพิเศษเช่นWebAuthenticationBrokerบน Windows 8 เพื่อควบคุมและเข้าถึงการตอบสนองการเปลี่ยนเส้นทาง HTTP

หวังว่านี่จะช่วยได้

เปโดร

TL; DR:ใช้ Authorization Code Grant กับPKCE

1. ประเภทการให้สิทธิ์โดยปริยาย

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

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

และเมื่อรวมกับข้อเท็จจริงที่ว่าจะไม่ให้คุณรีเฟรชโทเค็นการเข้าถึงควรหลีกเลี่ยง

2. รหัสการให้สิทธิ์ประเภทการให้สิทธิ์

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

เราขอแนะนำให้ใช้ App Access Token จากเซิร์ฟเวอร์ของแอปโดยตรงเท่านั้นเพื่อให้เกิดความปลอดภัยที่ดีที่สุด สำหรับแอพที่มาพร้อมเครื่องเราขอแนะนำให้แอปสื่อสารกับเซิร์ฟเวอร์ของคุณเองและเซิร์ฟเวอร์จากนั้นส่งคำขอ API ไปยัง Facebook โดยใช้ App Access Token

ไม่ใช่ทางออกที่ดี แต่มีวิธีใหม่ที่ดีกว่าในการทำ OAuth บนอุปกรณ์มือถือ: รหัสพิสูจน์สำหรับการแลกเปลี่ยนรหัส

3. Authorization Code Grant Type with PKCE (Proof Key for Code Exchange)

เทคนิคใหม่ถูกสร้างขึ้นเพื่อให้คุณใช้ Authorization Code ได้โดยไม่ต้องใช้ความลับของไคลเอ็นต์ คุณสามารถอ่านRFC 7636ฉบับเต็มหรือบทนำสั้น ๆนี้

PKCE (RFC 7636) เป็นเทคนิคในการรักษาความปลอดภัยไคลเอนต์สาธารณะที่ไม่ใช้ความลับไคลเอนต์

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

จากhttps://oauth.net/2/pkce/

การใช้ Webview ในแอปพลิเคชันมือถือของคุณควรเป็นวิธีที่เหมาะสมในการใช้งานโปรโตคอล OAuth2.0 บนแพลตฟอร์ม Android

สำหรับฟิลด์ redirect_uri ฉันคิดว่าhttp://localhostเป็นทางเลือกที่ดีและคุณไม่จำเป็นต้องพอร์ตเซิร์ฟเวอร์ HTTP ภายในแอปพลิเคชันของคุณเพราะคุณสามารถแทนที่การนำonPageStartedฟังก์ชันไปใช้งานในWebViewClientคลาสและหยุดการโหลดหน้าเว็บได้http://localhostหลังจากที่คุณตรวจสอบurlพารามิเตอร์

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}

ประสบการณ์ของผู้ใช้ที่ราบรื่นที่สุดสำหรับการตรวจสอบสิทธิ์และวิธีที่ง่ายที่สุดในการนำไปใช้คือการฝัง Webview ในแอปของคุณ ประมวลผลการตอบกลับที่ได้รับจาก webview จากจุดตรวจสอบสิทธิ์และตรวจหาข้อผิดพลาด (การยกเลิกของผู้ใช้) หรือการอนุมัติ (และแยกโทเค็นจากพารามิเตอร์การสืบค้น URL) และฉันคิดว่าคุณทำได้จริงในทุกแพลตฟอร์ม ฉันทำงานนี้สำเร็จแล้ว: ios, android, mac, แอพ windows store 8.1, แอพ windows phone 8.1 ฉันทำสิ่งนี้เพื่อบริการต่อไปนี้: dropbox, google drive, onedrive, box, basecamp สำหรับแพลตฟอร์มที่ไม่ใช่ windows ฉันใช้ Xamarin ซึ่งคาดว่าจะไม่เปิดเผย API เฉพาะแพลตฟอร์มทั้งหมด แต่ก็เปิดเผยเพียงพอสำหรับการทำให้เป็นไปได้ ดังนั้นจึงเป็นโซลูชันที่เข้าถึงได้ง่ายแม้จะมองจากมุมมองข้ามแพลตฟอร์ม