OAuth ภายใน VPN: ส่วนใดบ้างที่ยังต้องใช้ TLS

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

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

ตัดสินใจตามเส้นทาง ไม่ใช่ตามเครือข่าย

จดปลายทางแยกกันไว้: authorization endpoint, token endpoint, redirect URI, URL ของ resource server, จุดสิ้นสุด TLS และ VPN gateway จากนั้นทำเครื่องหมายว่าฝ่ายใดเป็นผู้เริ่มคำขอแต่ละรายการ และคำตอบไปที่ใด

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

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

การตอบกลับการอนุญาตและ redirect URI

แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัยในปัจจุบันของ OAuth ห้ามส่งการตอบกลับการอนุญาตผ่านการเชื่อมต่อที่ไม่เข้ารหัส ซึ่งครอบคลุม redirect ที่นำ authorization code หรือ token กลับไปยังไคลเอนต์ ไม่ใช่แค่คำขอเริ่มต้นเท่านั้น

คำแนะนำเดียวกันไม่อนุญาต redirect URI แบบ HTTP ยกเว้นกรณี loopback ของไคลเอนต์เนทีฟที่ระบุไว้ ชื่อโฮสต์ภายในไม่ได้สร้างข้อยกเว้นใหม่ และชื่อ DNS ที่แปลงได้เฉพาะภายใน VPN ก็ยังเป็น URL แบบ HTTP หาก scheme บอกเช่นนั้น ให้ตรวจสอบ scheme ใน URI ที่ลงทะเบียน ไม่ใช่แค่ชื่อโฮสต์

ลงทะเบียน redirect URI แบบ HTTPS ที่ตรงเป๊ะกับเซิร์ฟเวอร์อนุญาต และเปิดการตรวจสอบใบรับรองไว้บนไคลเอนต์ ทางลัดสำหรับการพัฒนาที่ปิดข้อกำหนด HTTPS จะสร้างโฟลว์ที่ทำงานต่างจากการกำหนดค่าสำหรับใช้งานจริงที่มันควรจำลอง

token endpoint และคำขอแบบ bearer token

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

สำหรับคำขอทรัพยากรแบบ bearer token นั้น RFC 6750 ถือว่า TLS เป็นข้อบังคับให้ต้องนำไปใช้และใช้งานสำหรับข้อกำหนดนั้น การเรียกซับเน็ตของสำนักงานว่าน่าเชื่อถือไม่ใช่ข้อยกเว้นทั่วไปของโปรโตคอลที่การติดตั้งแบบ bearer แบบข้อความธรรมดาต้องการ

ใช้ URL ของปลายทางที่ปลอดภัยตามที่เอกสารระบุสำหรับทั้งสองเส้นทาง หากไลบรารีปฏิเสธที่จะเรียก token endpoint แบบ HTTP การปฏิเสธนั้นคือข้อกำหนดที่ทำงานอยู่ ไม่ใช่บั๊กของการกำหนดค่าที่ต้องหลีกเลี่ยง บันทึก URL นั้นไว้ในการกำหนดค่าของไคลเอนต์แทนการคำนวณตอนรันไทม์

TLS สิ้นสุดที่ใด และเหลืออะไรไว้

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

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

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

ข้อยกเว้น loopback ของเนทีฟนั้นแคบ

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

จำกัดข้อยกเว้นให้อยู่ในขอบเขตของประเภทไคลเอนต์และ callback ที่มันอธิบายไว้ การนำไปใช้กับเว็บแอปพลิเคชัน บริการภายในที่ใช้ร่วมกัน หรือ redirect URI บนโฮสต์อื่นเป็นการเปลี่ยนการติดตั้ง ไม่ใช่ข้อยกเว้น

ทดสอบโฟลว์จริงที่แต่ละขอบเขตและเปรียบเทียบกับประเภทไคลเอนต์ redirect ที่ทำงานได้ไม่ได้บอกอะไรเลยว่าทุกเส้นทางที่พา token ใช้การป้องกันที่กำหนดหรือไม่ และไอคอน VPN สีเขียวก็ไม่ได้บอกอะไรเกี่ยวกับ scheme ของคำขอถัดไป