OAuth มีกี่โฟลและทำงานกับ OIDC อย่างไร?

จาก Blog ที่ผ่านมาเรื่อง ลงลึกกับ OAuth กันดีกว่า ผมได้อธิบายการทำงานของ OAuth โดยยกตัวอย่างโฟลต่างๆไปแล้วนั้น Blog นี้จะขอเน้นไปที่ OAuth และ OIDC รวมถึงโฟลต่างๆของ OAuth ว่าตกลงมันมีกี่แบบกันแน่ และแต่ละแบบมันต่างกันอย่างไร

ในส่วนของ OAuth 2.0 นั้น จะประกอบไปด้วย 4 โฟล หลักๆ แต่จะแตกต่างกันในรายละเอียดและการนำไปใช้ ดังนี้

  • Authorization Code (ทำงานทั้ง Front Channel + Back Channel)
  • Implicit (ทำงานเฉพาะ Front Channel)
  • Resource Owner Password Credential (ทำงานเฉพาะ Back Channel)
  • Client Credential (ทำงานเฉพาะ Back Channel)

ปัจจุบันจะมีสองโฟลที่ใช้งานบ่อยๆ คือ Authorization Code Flow (ปลอดภัยสูงสุด) ใช้งานกับ Web Application ที่มีทั้ง Backend + Frontend ในการทำงาน และ Implicit Flow จะทำงานเฉพาะ Front Channel มักจะใช้กับการทำงานของ Application ที่ไม่มี Backend หรือการทำงานเกือบทั้งหมดเกิดขึ้นที่ Frontend เช่น SPA (Single Page Application) เป็นต้น

ในส่วนของอีกสองโฟลที่เหลือคือ Client Credential ใช้กับการเชื่อมต่อระหว่าง Machine to Machine ไม่มี Frontend มาเกี่ยวข้อง เช่น การเชื่อมต่อระหว่าง Server และ API ต่างๆ เป็นต้น ซึ่งจะอธิบายในภายหลัง ในส่วนของ  Resource Ower Password Credentail ไม่แนะนำให้ใช้ (หากไม่จำเป็น) เพราะเอาไว้ใช้กับ Service เก่าๆ และบาง Use Case มากกว่า ดังนั้นจะยังไม่ขอกล่าวถึงในขณะนี้นะครับ

 

จากภาพจะแสดงถึงโฟลที่เปลี่ยนไปเล็กน้อยจาก OAuth Authorization Code คือ จะไม่มี Backend มาเกี่ยวข้อง ทุกอย่างจบที่ Frontend ทั้งหมด โดยเริ่มจากโฟลที่ (1) เปลี่ยน Response Type เป็น token เพื่อบอก Authorization Code ว่าจะใช้โฟลแบบ Implicit  โดยเมื่อผู้ใช้งาน (Resource Owner) ทำการ Consent เรียบร้อยแล้ว Authorization Server จะส่ง Access Token กลับไปยัง Client Application ทันทีโดยที่ไม่ต้องทำการ Validate Authorization Code อีกรอบ ซึ่งจะเป็นการลดระดับความปลอดภัยลงไป หากเทียบกับ Authorization Code Flow แต่จะทำให้ Application ที่ไม่มี Backend เช่น SPA (Single Page Application) สามารถนำ Access Token ไปทำงานต่อได้ทันที โดยจากภาพ SPA ได้รับ Access Token แล้วนำไปขอ Public Profile และ Contact จาก Google (Resource Server) ได้ทันที ง่ายกว่า เร็วกว่า แต่ปลอดภัยน้อยลง ดังนั้นวิธีนี้จะเหมาะกับพวก SPA และ Intranet มากกว่านะครับ ก่อนเอาไปใช้งานขอให้ระวังเรื่องนี้ด้วย

เอาละ ผมคิดว่าหลายๆท่านน่าจะเริ่มเข้าใจภาพของ OAuth มากขึ้นกว่าเดิม แต่เดี๋ยวก่อน Blog แรกๆ บอกว่า OAuth เป็น Authorization Framework นี่ แต่ดูๆละเหมือนกับว่าเราเอา OAuth มาทำ Authentication หรือเปล่า ละตกลงเอามันมา Authentication ได้ด้วยใช่ไหม แล้วอะไรคือ Open ID Connect จะโผล่มาตอนไหน มันเกี่ยวกันยังไง OAuth ยังไง? โอเค….เรามาเข้าเรื่องกันเลยดีกว่าครับ!

เริ่มจากการ OAuth มาใช้เพื่อ Authentication มันไม่ดียังไง?

OAuth ออกแบบมาสำหรับ Authorization ดังนั้นมันจะ Focus ที่ Scope, การแลกเปลี่ยน Authorization Code กับ Access Token, การเข้าถึง Resource ต่างๆ แต่การ Authentication ผู้ใช้งานจะต้องส่งข้อมูลบางอย่างเข้ามาเพื่อ Authentication กับระบบ เช่น E-Mail, User / Password เป็นต้น ซึ่ง OAuth ไม่มีมาตรฐานในเรื่องของ การดึง User Information ออกมา หมายความว่า หากระบบงานไหน มีปุ่ม Login ด้วย Facebook, Google แล้วใช้ OAuth ในการทำ Authentication จะต้องมีการเขียน Code เพิ่ม เพื่อดึง User Information ออกมา จาก Resource Server ต้องมีการ Customize ที่แตกต่างกันในแต่ละ Application ซึ่งมันดูแย่ๆ และไม่ได้แก้ปัญหาที่มีอยู่เดิมใช่ไหมครับ

แล้วอะไรที่แก้ปัญหา สิ่งที่แก้ปัญหาคือ OpenID Connect (OIDC) ไงล่ะ!

 OpenID Connect (OIDC) เป็น Protocol ที่เกิดขึ้นมาเพื่อเป็น Extendtion ในการทำงานร่วมกับ OAuth 2.0 โดยมองเสมือนว่า “เฮ้! ถ้าต้องการใช้ OAuth ทำการ Authentication ให้ทำ Step เพิ่มโดยใช้ OIDC” ซึ่งแบ่งหน้าที่ดังนี้

  • OpenID Connect เพื่อทำการ Authentication โดย Login User เข้าสู่ระบบ และส่งข้อมูลผู้ใช้งานไปยังระบบงานอื่นๆ
  • OAuth เพื่อทำ Authorization โดย Grant Access ให้กับ Client API และ Grant Access User Data ในระบบงานอื่นๆ

OpenID Connect แก้ปัญหาเรื่อง Authentication ให้กับ OAuth โดยเพิ่ม Components ต่างๆดังนี้

  • User ID Token – Encode ของ User Information
  • User Info endpoint เพื่อร้องขอ User Information – ถ้า User ID Token ที่ส่งกลับมา มีข้อมูลไม่ครบตามที่ Client จะต้องใช้ สามารถร้องขอกลับไปยัง User Info endpoint เพื่อขอข้อมูลเพิ่มเติมกลับมาได้
  • Scope มาตรฐานสำหรับการร้องขอ User Information – หาก Client ทำการร้องขอ Access Token ไปยัง Authorization Server ที่รู้จัก OIDC แล้ว Client ยังสามารถร้องขอ User ID Token เพิ่มเติมได้อีกด้วย

ทีนี้เราลองมาดูกันว่าหากเพิ่ม OIDC เข้าไปใน OAuth Flow แล้วหน้าตาจะเป็นอย่างไร

จากภาพจะเป็น Flow OpenID Connect Authorization Code ซึ่งเห็นได้ว่ามีการปรับเปลี่ยนโฟลแรก (1) โดยเพิ่ม Scope “OpenID” เข้ามา เพื่อบอก Authorization Server ว่าต้องการใช้ OIDC ผ่าน OAuth จากนั้น Authorization Server จะทำการ Authentication และ Consent , ส่ง Authorization Code กลับไปยัง Client ตามปกติ จนกระทั่งโฟลที่ (4)  ที่เมื่อ Client Backend นำ Authorization Code แลก Access Token ผ่าน Back Channel นั้น Authorization Server จะส่งทั้ง Access Token และ ID Token กลับมาพร้อมๆกัน และ Client Application สามารถนำ ID Token ไป Decode เพื่อแปลงกลับเป็น User Information และแสดงผลใน Client Applicationได้เลย รวมถึงหากว่าข้อมูลที่ได้รับไม่เพียงพอ ยังสามารถเพิ่มโฟล (5) เพื่อร้องขอข้อมูลเพิ่มเติมผ่าน Endpoint ที่เป็นมาตรฐานจาก Resource Server โดยใช้ Access Token เดิมได้อีกด้วย ง่ายขึ้นเยอะเลย 🙂

ทั้งนี้สามารถศึกษาเพิ่มเติมได้ผ่าน Link ด้านล่างนะครับ ครบถ้วนตรงไปตรงมา

Reference : Understanding ID Token

ในส่วนของโฟลที่เป็น Resource Owner Password Credential นั้น ออกแบบมาเพื่อใช้งานกับระบบงานเก่าๆ ที่ไม่รองรับการแก้ไข Protocol วิธีนี้ไม่แนะนำให้ใช้งานหากไม่จำเป็นจริงๆ เพราะผู้ใช้งาน (Resource Owner) จะต้องพิมพ์ User / Password ผ่าน Client (แค่นี้ก็ไม่น่าใช้งานละครับ) ในส่วนของ Client จะส่ง Request ไปยัง Authorization Server ในลักษณะดังนี้

“https://oauth.tamacorp.co/token?type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID”

 

โฟลสุดท้ายที่เป็น Client Credential นั้น ออกแบบมาเพื่อใช้งานกับ Machine to Machine หรือ API to API โดย Client จะส่ง Client ID และ Client Secret ส่งไปให้ Authorization Server เพื่อขอใช้งาน Resource เมื่อ Authorization Server ทำการ Validate Client ID และ Client Secret เรียบร้อยแล้ว จะส่ง Access Token กลับไปให้กับ Client เพื่อใช้ในการ Access Resources จาก Resource Server ต่อไป

ในส่วนของ Client จะส่ง Request ไปยัง Authorization Server ในลักษณะดังนี้

“https://oauth.tamacorp.co/token?type=client_credential&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

ผ่านไปสำหรับ 4 โฟล หลักของ OAuth ต่อไปเพื่อให้เห็นภาพรวมมากขึ้น ลองมาดู Security Requirements หลักๆ ที่เกี่ยวข้องกับ Authentication / Authorization ของแอพลิเคชั่นว่าตั้งแต่อดีตจนปัจจุบัน (2019) มีอะไรบ้างครับ

  • Web Application Login – การ Login เข้าใช้งาน Web Application
  • Single Sign-On across sites – การ Login ครั้งเดียว สามารถใช้งานข้าม Site ได้
  • Mobile Application Login – การ Login ของ Mobile Application
  • Delegated Application Authorization – การกำหนดสิทธิในการถึง Application

ขอยก Use Cases การใช้งานหลักๆ ที่เป็นการ Login จาก Web, มือถือ, การทำ SSO ข้าม Site และ Delegated Authorization ซึ่งหากเราจะมองย้อนกลับไป Security Requirements ต่างๆเหล่านี้ มีมาตั้งแต่ช่วงใช้งาน Internet มี Web Application ใหม่ๆ  ยกเว้นมือถือที่น่าจะมี Requirements นี้ สมัย Iphone รุ่นแรกเริ่มวางตลาด และยังคงมี Requirements ดังกล่าวมาจนถึงปัจจุบัน หากแต่ปรับเปลี่ยนมาตรฐานที่ใช้ในแต่ละเรื่องไปตามเวลา

ประมาณช่วง 200x-2010

  • Web Application Login (ใช้ Form Submit และ Cookie) – ใช้เพื่อ Authentication
  • Single Sign-On across site (ใช้ SAML) – ใช้เพื่อ Authentication
  • Mobile Application Login (ยังไม่มี Requirements นี้ เพราะ Mobile Application ยังไม่แพร่หลาย)
  • Delegated Application Authorization (มี Requirements นี้แต่ยังไม่มี Protocol มารองรับแบบเป็นมาตรฐาน)

ประมาณช่วง 2010-2015

  • Web Application Login (OAuth 2.0) – ใช้เพื่อ Authentication
  • Single Sign-On across site (OAuth 2.0) – ใช้เพื่อ Authentication
  • Mobile Application Login (OAuth 2.0) – ใช้เพื่อ Authentication
  • Delegated Application Authorization (OAuth 2.0) – ใช้เพื่อ Authorization

ช่วงนี้เริ่มมีการใช้ OAuth กันแล้วแต่ยังไม่มีมาตรฐานกันเท่าที่ควร เพราะข้อจำกัดของ OAuth ในเรื่องของ Authentication ในปี 2014 จึงมีการ Publish มาตรฐาน OpenID Connect 1.0 (อ้างอิง OpenID) และเริ่มมีการพัฒนา Application ตามมาตรฐานดังกล่าว จนมาเป็นปัจจุบัน

ประมาณช่วง 2015-ปัจจุบัน

  • Web Application Login (OpenID Connect) – ใช้เพื่อ Authentication
  • Single Sign-On across site (OpenID Connect) – ใช้เพื่อ Authentication
  • Mobile Application Login (OpenID Connect) – ใช้เพื่อ Authentication
  • Delegated Application Authorization (OAuth 2.0) – ใช้เพื่อ Authorization

แล้ว Use Cases อื่นๆ ที่แตกต่างไปจากที่ตัวอย่าง ควรจะใช้แบบไหนดี? ขอยกตัวอย่างคร่าวๆดังนี้ครับ

จากหลายๆบทความที่ผ่านมา หวังว่าทุกท่านจะได้ความรู้ และมีความเข้าใจมากขึ้น ว่า OIDC กับ OAuth ต่างกันในการนำไปใช้งานอย่างไร, Application แบบไหน ควรใช้โฟล แบบไหนนะครับ ทั้งนี้หลายๆอย่างเขียนตามความเข้าใจที่ศึกษา มาจากหลายๆแหล่ง เลยอยากรวบรวมและเขียนเป็นภาษาไทยให้หลายๆคนได้อ่านและทำความเข้าใจการทำงานของมันและเลือกใช้ได้ถูกกับงานนะครับ 🙂

ถ้า Application ของทุกคน Secure ด้วยความรู้ ความเข้าใจ โลกอินเตอร์เนตของพวกเราก็จะ Secure ตามไปด้วยเช่นกันครับ 🙂


Leave a Reply