OAuth 2.0 กับ Grant Types ทั้ง 6

Sakul Montha
4 min readMar 23, 2019

--

สวัสดีครับผู้อ่านทุกท่าน หลายวันก่อนผมได้มีโอกาสไปช่วยเทรน nodejs แล้วมีน้อง ๆ หลายคนเกิดสนใจเกี่ยวกับการทำ Authen อยากให้เปิดคลาสเรื่อง OAuth 2.0 จึงเป็นที่มาของเรื่องที่จะเขียน… วันนี้ผมจะพาทัวร์ OAuth 2.0 และ Grant Types ในรูปแบบต่าง ๆ มันมันคืออะไร แล้วแต่ละ Grant Types มันแตกต่างกันอย่างไร

อันที่จริง OAuth มันยังมีอย่างอื่นอีกเยอะนะครับ ไม่ว่าจะเป็นการทำ Mobile and Other Devices, Token Management, Related Specs and Extensions, และอื่น ๆ ที่จะไม่ได้กล่าวถึง เนื่องจากมันเยอะมาก แนะนำให้ไปอ่าน RFC ต่อ

https://oauth.net

OAuth 2.0

OAuth 2.0 เป็น Industry-standard protocol ใช้สำหรับการทำ Authorization framework เปิดให้ third-party application ได้รับสิทธิ์การเข้าถึง โดยเป็นที่นิยมมาก ๆ ในปัจจุบัน RFC6749
OAuth 2.0
เข้ามาแทนตัว Original OAuth protocol ที่ถูกสร้างมาตั้งแต่ปี 2006
OAuth 2.0 เน้นไปที่ความเรียบง่ายให้สำหรับฝั่ง Client ในการพัฒนาการทำ Authorization flows ทั้ง Web Application, Desktop Application, Mobile Phone และอื่น ๆ

OAuth 2.0 ที่จะกล่าวต่อไปนี้ จะแบ่ง ออกได้ 3 ส่วน

Resource Owner (User) <-> 1st Party App (Client) <-> Server (Authorization Server และ Resource Server)

ภาพ 3 ส่วนใหญ่ ๆ ของ Flow

Server (Authorization + Resource Server)

Server ออกเป็นสองส่วน Authorization Server, Resource Server โดยภายใน Resource Server อาจจะมี Microservices เล็ก ๆ อีกมากมายก็ได้ ถ้าคุณเป็นผู้สร้าง ก็คือคุณจะอยู่ในส่วนของ Authorization ใน Authorization จะทำหน้าที่ผลิต Auth Code กับ Access Token ให้ Client และ Resource Server จะทำหน้าที่ไปหาของมาให้ตามที่ User ร้องขอตามข้อมูล และ Scope ที่มี ในบทความนี้จะไม่เจาะลึกถึงหน้าที่ต่าง ๆ ของ 2 ตัวนี้มากนัก และจะเรียกส่วนนี้ว่า Server

ตัวอย่าง Facebook เป็นผู้ให้บริการ Service เปิด API ต่าง ๆ ให้คนอื่น มองว่าเขาเป็นฝั่ง Authorization และ Resource Server

1st Party App or (Client)

1st Party App (Client) คือ ตัวกลางที่จะเข้ามาเชื่อมต่อกับทาง Server ตัว Client ไม่ใช่ User นะครับ Client ถือเป็นคนกลาง ในการเชื่อมต่อ ถ้าคุณเป็นผู้ใช้งาน หรือ 1st Party App คุณคือ Client

กรณีเราเป็นคนสร้าง App มาซัก App เช่น App Game ซึ่งต้องการให้ผู้ใช้ Login ผ่าน Account Facebook เราก็จำเป็นที่จะต้องเชื่อมต่อกับ Facebook นี่ก็ถือว่าเราเป็นฝั่ง Client แล้ว

Resource Owner (User)

ถ้าคุณแค่มาขอเขาใช้ คุณคือ User หรือ Resource Owner นั่นเอง

คุณต้องการ Login game สักเกมส์นึงแต่ต้อง Login ผ่าน Facebook แล้วคุณก็ให้สิทธิ์ App game นั้น ๆ ในการเข้าถึงข้อมูลส่วนตัวของคุณ นี่คือคุณเป็นฝั่ง Resource Owner หรือ User นั่นเอง

Authorization กับ Authentication นั้นไม่เหมือนกันนะครับ
Authorization เป็นการมอบสิทธิ์ให้กับผู้ใช้
Authentication เป็นการยืนยันตัวตน
จะได้ไม่จำกันสับสน

OAuth 2.0 Grant Types

ประเภทของ Grant Types ใน OAuth 2.0 ที่นิยมใช้กันมากที่สุดมีอยู่ 6 ประเภท

Authorization Code

Authorization Code เป็นประเภทการให้สิทธิ์ลูกค้าเพื่อนำ Authorization code หรือที่เรียกกันสั้น ๆ ว่า Auth code มาแลกเปลี่ยนเป็น Access token เพื่อให้ลูกค้าใช้ Access Token ในการเข้าใช้งาน Resource…

ตรงส่วนนี้ Server หรือผู้ให้บริการ และ Client ต้องคุยกันว่าจะแลกเปลี่ยน Auth code กันแล้วให้ Server หรือผู้ให้บริการทำการ Redirect URL ไปยัง URL ใด เพื่อนำมาแลกเป็น Access Token //RFC

Implicit

Grant Type Implicit เป็นการให้สิทธิ์แบบง่าย ที่สามารถใช้ได้โดย Public clients โดยที่ Server จะส่ง Access Token คืนให้ทันที โดยไม่ต้องมีการทำการ Authorization code หรือ Auth Code ก่อน เหมือนในโฟลว์ข้างบน

โดยทั่วไปจะไม่แนะนำให้ใช้ Implicit flow (หลาย ๆ ที่ไม่อนุญาตให้มี flow นี้เลย) ถ้าหากต้องการใช้ Implicit flow จริง ๆ OAuth 2.0 เขาจะแนะนำให้ใช้ Authorization code ด้วย Proof Key for Code Exchange (PKCE) แทน

ส่วนตัวเห็นว่าวิธีนี้เป็นวิธีที่ง่ายกว่าจริง แต่ก็ต้องแลกมากับความเสี่ยงด้วยเนื่องจาก ไม่มีการทำ Authorization code ก่อน แต่ Trust client เลย //RFC

Password (Resource Owner Password Credentials)

Grant type Password เป็นการให้ Password ของ User โดยจะถูกใช้งานจาก User เอง ดังนั้นจึงไม่ควรให้บุคคลที่สาม หรือ Client เข้ามาใช้โฟลว์นี้ จะเป็นอารมณ์ลูกค้าขอรหัสผ่านของตัวเองโดยผ่านทาง Access Token โดยตรง //RFC

Client Credentials

Client Credentials เป็น Grant type ที่ให้สิทธิ์ Client รับ Access Token ไปเพื่อเข้าถึงข้อมูลของตัว Client เอง ไม่ใช่เป็นการให้ Token ในการเข้าถึงข้อมูลของ User

RFC

Device Code

Device Flow คือการที่ Client ที่เชื่อมต่อ Internet ได้แต่ไม่มี ช่องทางการรับ Input ขอ Authorization จาก Authorization server โดยให้ User เป็นคนดำเนินการตามคำแนะนำจาก Device ผ่าน Secondary device

ตัวอย่างเช่น User เปิดเว็บ Youtube ในมือถือ แล้วกรอกรหัสที่แสดงบนทีวี เพื่อให้สิทธิ Apple TV ในการ Access data จาก Youtube server

สังเกตุว่า ในกรณีนี้ ไม่จำเป็นที่ Apple TV และ มือถือของ user จะต้องมี connection ระหว่างกัน แค่สามารถต่อ internet ได้ทั้งคู่ก็พอแล้ว

Device Code grant type value isurn:ietf:params:oauth:grant-type:device_code. //RFC

Refresh Token

Grant Type Refresh Token ถูกใช้โดย Client เพื่อนำมาแลกเปลี่ยน Access Token เมื่อ Access Token หมดอายุแล้ว

โดยมาก Refresh Token จะมีอายุมากกว่า Access Token อยู่แล้ว ทาง Client ที่มาติดต่อกับ Server จะมี Refresh Token เก็บเอาไว้ใช้ในยามที่ Access Token ของ User หมดอายุ แล้วนำ Refresh Token มาขอ Access Token ใหม่

RFC

Conclusion

ก็จบกันไปแล้วครับสำหรับ OAuth 2.0 และ Grant Types ทั้ง 6 หวังว่าผู้อ่านจะได้ความรู้มากขึ้นนิดนึงก็ยังดี จะได้ทราบว่าแต่ละ Grant Types มีเอาไว้ทำอะไรบ้าง จะได้ใช้ถูก รวมถึง ในบทความนี้ก็ไม่ได้กล่าวถึง Scope ในการให้ Client ทำการ Access เข้ามาใช้ทรัพยากรใน Server ด้วย ที่เขียนมาทั้งหมดนี่ค่อนข้างจะเป็น Concept มากกว่า เอาไว้โอกาสหน้า จะมาพูดถึงการ Implement ทั้ง Authorization Server และ Resource Server รวมถึงการ Implement Grant Type ในแต่ละแบบนะครับ

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

--

--

Sakul Montha
Sakul Montha

Written by Sakul Montha

Chief Product Officer, a man who’s falling in love with the galaxy.

Responses (1)