Introducing OAuth and OpenID
05 Oct 2016OAuth กับ OpenID ถูกพูดถึงมากในการทำ Token-Based Authentication เราจะมาทำความเข้าใจว่ามันคืออะไรก่อน แล้วค่อยลงรายละเอียดเชิงเทคนิคในโอกาสต่อไป
สมมุติ
เริ่มจากลองจินตนาการว่ามีโรงพยาบาลแห่งหนึ่งในประเทศสารขันธ์ซึ่งทุกจุดที่ติดต่อกับประชาชนจะมีการติดตั้งเครื่องอ่านบัตรประจำตัวประชาชนและเครื่องอ่านลายนิ้วมือเอาไว้ ถ้าประชาชนคนใดเข้าไปติดต่ออะไรเช่น มาเข้าคิวรอตรวจ ก็จะต้องนำบัตรประชาชนมาอ่านข้อมูลแล้วยืนยันด้วยลายนิ้วมือ แล้วเอาข้อมูลไปเปรียบเทียบกับกรมการปกครอง เพื่อจะระบุตัวตนของผู้มาใช้บริการและนำไปตรวจสอบสิทธิ์การใช้บริการที่เข้าถึงได้ต่อไป นั่นคือเมื่อประชาชนเข้าไปพบแพทย์ จ่ายค่ายา หรือไปรับยา ทุกๆจุดก็จะต้องยื่นบัตรประชาชนให้เจ้าหน้าที่แล้วก็สแกนลายนิ้วมือทุกจุดทุกครั้ง ดูเผิน ๆ ก็เหมือนจะทันสมัยดี แต่ลองเทียบกับโรงพยาบาลอีกแห่งก่อนละกัน
มีโรงพยาบาลที่ใช้วิธีต่างไปคือ โรงพยาบาลนี้จะใช้บัตรแบบเอาไปจ่อกับเครื่องอ่านโดยไม่จำเป็นต้องสัมผัส(คล้าย ๆ กับแบบที่ใช้จ่ายเงิน 7-11) ประชาชนที่มาใช้บริการที่โรงพยาบาลแห่งนี้จะต้องนำบัตรประจำตัวประชาชนมาอ่านข้อมูลแล้วยืนยันด้วยลายนิ้วมือ แล้วเอาข้อมูลไปเปรียบเทียบกับกรมการปกครองที่จุดลงทะเบียนของโรงพยาบาลก่อนที่จะไปใช้บริการยังจุดอื่น ๆ ได้ เมื่อตรวจสอบยืนยันข้อมูลเรียบร้อย เจ้าหน้าที่โรงพยาบาลจะออกบัตรชั่วคราวที่ใช้กับเครื่องอ่านบัตรของโรงพยาบาลให้ ซึ่งเครื่องอ่านบัตรมีติดตั้งอยู่ทุกจุดที่ให้บริการประชาชน(เหมือนกับที่โรงพยาบาลเดิมติดตั้งเครื่องอ่านบัตรประจำตัวประชาชนและเครื่องอ่านลายนิ้วมือไว้ทุกจุด) ดังนั้น เมื่อประชาชนได้รับบัตรของโรงพยาบาลแล้วต้องการไปใช้บริการที่จุดใดก็ตามในโรงพยาบาล ก็แตะบัตรกับเครื่องอ่านเจ้าหน้าที่ก็สามารถให้บริการได้เลย แล้วตอนจะออกจากโรงพยาบาลก็สอดบัตรคืนโรงพยาบาลเพื่อเปิดประตูกลับบ้าน
จะเห็นว่าทั้งสองโรงพยาบาลที่กล่าวมามีการตรวจสอบและยืนยันตัวตนทั้งคู่ แต่กระบวนการที่แตกต่างกันทำให้โรงพยาบาลหลังประชาชนได้รับความสะดวกกว่ามาก ส่วนโรงพยาบาลแรกแทนที่จะได้รับบริการในทันทีเจ้าหน้าที่และประชาชนต้องเสียเวลาในการตรวจสอบยืนยันตัวตนทุกครั้ง
ถ้าเปรียบกับระบบ IT จุดต่าง ๆ ที่ประชาชนไปยื่นแบบฟอร์ม ไปติดต่อ หรือเข้าไปใช้บริการ ก็คือการที่เราส่งคำขอ(Request)ไปยังเครื่องแม่ข่าย(Web Server)นั่นเอง วิธีการของโรงพยาบาลแรกคือทุก ๆ request ต้องมีการระบุยืนยันตัวตน เกิดความไม่สะดวกและเสียเวลา ส่วนวิธีการของโรงพยาบาลที่สอง จะแยกการตรวจสอบยืนยันออกมา แล้วออกหลักฐานให้นำไปแสดงเมื่อไปใช้บริการในโรงพยาบาลตามจุดต่าง ๆ ทำให้เกิดความสะดวกรวดเร็วขึ้น เปรียบไปแล้วก็คือก่อนจะดำเนินการใด ๆ ได้เราต้องระบุตัวตนให้ได้ก่อนเป็นขั้นตอนที่แยกออกมาก่อนทำ request ใดๆ และจะได้หลักฐานที่นำไปแสดงประกอบทุกครั้งที่มีการส่ง request ไปยัง Web Server
เข้าเรื่อง
ถ้าเอาตามทฤษฏี หลักฐานที่โรงพยาบาลออกให้ในเรื่องสมมุติของเรา ก็คือสิ่งที่เรียกว่า token ในโลกของ OAuth นั่นเอง ลองลำดับการทำงานจากเริ่มต้น ประชาชนต้องไปแสดงตัวต่อเจ้าหน้าที่ด้วยการแสดงบัตรประชาชนและสแกนลายนิ้วมือต่อหน้าเจ้าหน้าที่ เป็นขั้นตอนที่ภาษา IT เรียกว่าการทำ Authentication ซึ่งวิธีที่แพร่หลายที่สุดก็คงเป็นการ log in ด้วยการใส่ username และ password เมื่อตรวจสอบยืนยันเรียบร้อยเจ้าหน้าที่จึงออก token ให้ประชาชนพกติดตัวเพื่อนำไปแสดงทุกครั้งที่ส่ง request ไปที่ Web Server
หากจุดที่รับบริการบางจุดเข้าได้เฉพาะเจ้าหน้าที่ หรือผู้ได้รับอนุญาตเท่านั้น หากประชาชนแตะบัตรที่มีสิทธิ์ไม่ถึงก็จะไม่สามารถเข้าไปยังบริเวณดังกล่าวได้(ไม่เปิดประตูให้) แต่ถ้าเป็นบริเวณที่มีสิทธิ์เข้ารับบริการได้ก็จะสามารถเปิดประตูเข้าไปรับบริการได้ ขั้นตอนนี้เรียกเป็นภาษา IT ว่า Authorization
ถ้าระบบ IT ของเราแยกออกมาเป็น 2 ขั้นตอน(คือ Authentication ก่อนหนึ่งขั้นตอนแล้วค่อยทำ Authorization เป็นขั้นตอนถัดมา) จะทำให้ทุกครั้งที่เข้าไปยังจุดให้บริการต่าง ๆ (ในโลก IT คือส่ง request ไปที่ Web Server) จะทำให้ Web Server ทำงานน้อยลง เพราะไม่จำเป็นต้องทำ Authentication ทุกครั้งที่ได้รับ request
มาตรฐานของ OAuth ก็กล่าวถึงขั้นตอนที่ได้มาซึ่ง token และการตรวจสอบ token เมื่อได้รับ request นั่นเอง ส่วนขั้นตอนในการยืนยันบัตรประชาชนและสแกนลายนิ้วมือ ณ จุดลงทะเบียน ก็จะเป็นส่วนของ OpenID นั่นคือ OpenID จะบอกว่า ถ้าเรามี account ของ google แล้วเราต้องการเข้าไปใช้บริการของ website บางแห่งที่มี Google login เราจะถูกนำไปยังหน้า login ของ google อย่างไร และกลับมายัง website ที่เราต้องการใช้บริการจริง ๆ อย่างไร เปรียบเทียบไปก็เหมือนกับว่าจุดลงทะเบียนนั้นจะมีส่วนของ OpenID เป็นส่วนใหญ่ และเมื่อเจ้าหน้าที่ยืนยันตัวประชาชนแล้วในขั้นตอนการสร้างบัตรชั่วคราวของโรงพยาบาลหรือก็คือการออก token จะเกี่ยวข้องกับ OAuth และทุก ๆ ครั้งที่มี request และส่ง token ไปด้วย การตรวจสอบ token ก็เหมือนกับการแตะบัตรโรงพยาบาลที่เครื่องอ่าน ซึ่งนี่ก็ยังเป็นมาตรฐานของ OAuth นั่นเอง
สิ่งที่ขาดไป
โอ้ ถ้าอย่างนั้น OAuth กับ OpenID ก็เป็นเรื่องง่าย ๆ เท่านี้เองใช่มั้ย คำตอบคือทั้งใช่และไม่ใช่ หากเราเข้าใจกระบวนการของ OAuth กับ OpenID ที่กล่าวมาว่าเป็นกระบวนการง่าย ๆ คือมุมที่ใช่ ส่วนที่ไม่ใช่ก็คือมีแง่มุมที่ยังไม่ได้กล่าวถึงเหมือนกัน นั่นคือ
- ทำอย่างไรจะไม่สามารถปลอม token ได้
- Token ที่ออกมาอย่างถูกต้องแล้ว ห้ามถูกประชาชนแก้ไขข้อมูลโดยพลการ
- จะยืนยันว่าเป็น token แท้ได้อย่างไรจึงจะปลอดภัยและรวดเร็ว
ซึ่ง OAuth ก็ครอบคลุมเรื่องเหล่านี้อยู่แล้ว แต่รายละเอียดเป็นอย่างไร คงต้องอดใจรอบทความหน้าที่จะมาคุยกันต่ออีกทีนะครับ
สรุป
ขอสรุปด้วย ตารางเปรียบเทียบคำศัพท์และ concept ตามนี้นะครับ
ศัพท์ | ความหมาย | เปรียบเทียบ |
---|---|---|
Authorization | การตรวจสอบยืนยันตัวบุคคล | จุดลงทะเบียนประชาชนต้องยื่นบัตรประชาชนให้เจ้าหน้าที่เพื่ออ่านข้อมูลไปเปรียบเทียบกับกรมการปกครอง และต้องสแกนลายนิ้วมือประกอบว่าเป็นคนเดียวกันกับในบัตรจริง |
Authentication | การอนุญาตให้เข้าใช้งานตามสิทธิ์ที่มี | ถ้าประชาชนแตะบัตรกับเครื่องอ่านแล้วพบว่าไม่สามารถใช้บริการในบริเวณดังกล่าวได้จะไม่เปิดประตูให้เข้าไปใช้บริการ เช่นอาจจะเป็นบริเวณที่อนุญาตเฉพาะเจ้าหน้าที่หรือผู้บริหารเท่านั้น |
Token | หลักฐานทางดิจิตอลที่จะส่งไปพร้อมกับ request เพื่อให้ Web Server ทำการอนุญาตให้ระบบทำงานตามที่เราร้องขอ | หลักฐานที่ออกให้นำไปแสดงตามจุดให้บริการต่าง ๆ ในโรงพยาบาล เพื่อเข้าใช้บริการในส่วนนั้น ๆ |
บทความนี้เราอธิบาย OAuth โดยอ้างอิงตาม Standard ของ OAuth 2 ซึ่งแพร่หลายและเหมาะกับการใช้งานมากกว่า version 1