ติดตามการเข้าสู่ระบบ OmniAuth ผ่านพร็อกซี

ผู้ใช้คลิก “ลงชื่อเข้าใช้” ไปถึงหน้าของผู้ให้บริการแล้วกลับมาที่ Rails ขั้นตอนถัดไปยังอาจล้มเหลวได้ เพราะเป็นการเปิดการเชื่อมต่อใหม่จากเซิร์ฟเวอร์ Rails

browser → provider authorization page → browser callback to Rails
Rails   → provider token endpoint → Rails

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

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

ค้นหาการกำหนดค่าของไคลเอนต์

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

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

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