+++ access token คืออะไรใน facebook ++++
ปกติ facebook เปิดให้เว็บ (รวมทั้งแอพ) ที่เราเขียนขึ้น
สามารถใช้ระบบ login ของ facebook ได้
ทำให้เว็บนั้นได้สิทธิเข้าถึงข้อมูลส่วนตัวของ user นั้นๆ บน facebook

และในหลายเว็บไซต์ เราคงเคยเห็น
ขอแค่มีแอคเคาท์เฟสบุ๊คก็สามารถล็อกอินได้เลย
ไม่ต้องเสียเวลายุ่งยาก กรอกสมัครสมาชิกใหม่แต่อย่างใด

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

ก่อนจะพูดถึง access token ขอย้อนไปสมัยวัยกระเตาะปี 2534
เมื่อ “ทิม เบอร์เนิร์ส-ลี” ได้ทำคลอดเว็บไซต์แรกของโลก
จนเป็นสิ่งสามัญประจำบ้านที่มนุษย์โลกใช้เป็น

แต่จุดอ่อนของฉัน ….อยู่ที่หัวใจ
เฮยไม่ช่ายแหละ จุดอ่อนของเว็บไซต์
ก็คือมันใช้โปโตคอล HTTP
ซึ่งมันเป็นแบบ stateless ไม่จำสถานะอะไรทั้งนั้น
ความหมายก็คือ ตัว Server ความจำสั้นมาก เป็นโรคอัลไซเมอร์
พอมันรับ request จาก browser
ก็จำไม่ได้ว่ามาจากไหน???
ใครส่งมาจำไม่ได้แล้ว!!!!!

เพื่อแก้ปัญานี้ในทางเทคนิค
เขาจะให้ server ส่ง session id (หรือ session token)
ซึ่ง session id มันเป็นรหัสบางอย่าง ที่เราอ่านไม่ออก แถมยาวด้วย
มันจะถูกส่งไปให้ browser เก็บค่านี้ไว้ในคุ๊กกี้เสี่ยงทาย

..ผิดๆ ไม่ใช่คุ๊กกี้นั้น ..แต่ cookies ที่ว่าคือไฟล์ text
Server จะส่ง session id ไปให้ browser
เก็บค่าไว้ใน cookies (เก็บใส่ text อยู่ฝั่ง browser)

เวลาเขียนโปรแกรมในฝั่ง server
อย่าง PHP เมื่อใช้คำสั่ง session_start();
จะเป็นการบอกให้ browser เก็บค่า session id ในรูป text เช่น
PHPSESSID=tqb4s5q7k25234eabbvs11dp02
(session id เป็นรหัสที่สุ่มขึ้นมา)

แต่ถ้าเป็นภาษาอื่น ก็อาจเห็นเป็นคำอื่นนะครับ
เช่น JSESSIONID (Java EE), PHPSESSID (PHP), และ ASPSESSIONID (Microsoft ASP).

ถึงตรงนี้ session id …อาจมองว่าเป็นรหัสประจำตัวก็ได้

ต่อไปนี้เวลาผู้ใช้กดคลิกอะไรบนหน้าเว็บ
ทาง browser ก็จะใจดี
แอบส่ง session id ที่ว่านี้ ไปให้ server อัตโนมัติ
ทำให้ server หายจากอัลไซเมอร์
…จำได้แล้วว่า request ส่งมาจากไหน …เย้ เย้

ดังนั้นถ้าเกิด request ที่ส่งเข้ามา
มันมี session id ค่าเดียวกัน
ก็ถือว่าเป็นพรรคพวกเดียวกัน
(ศัพท์ทางคอมจะบอกว่า request พวกนี้อยู่ SESSION เดียวกัน)

แล้วถ้าไม่ใช่ session id เดียวกัน
ก็ถือว่า request นั้น ไม่ใช่พวกพ้องเดียวกัน

ประโยชน์ของ session id
จะถูกนำไปใช้ร่วมกับกลไก login/logout
1) เมื่อ user ชื่อ XXX ทำการ login เข้ามา ก็จะมี session id เป็นรหัสประจำตัวอันหนึ่ง
2) พออีก user ชื่อ YYY ทำการ login เข้ามา จะมี session id เป็นรหัสประจำตัวคนละตัว
3) พอทั้งสอง user ทำการ logout ก็จะทำให้ session id หมดอายุ

คำถาม ถ้าเราไปกดล้าง cookies ทั้งหมดใน browser จะเกิดอะไรขึ้น?
– คำตอบค่า session id จะหายไปหมด
– ดังนั้นใครแอบ login ค้างเว็บโป้ เว็บโน่นนี้นั่น อะไรไว้ …หึหึๆๆ
– ก็ต้อง logout อัตโนมัติ เพื่อ login ใหม่ …เศร้ามั๊ยละ
(server จำเราไม่ได้แล้ว
เพราะ browser ไม่ส่ง session id ไปให้)

เรื่อง session id ฟังเหมือนดี
แต่การใช้ร่วมกับ user/password เพื่อ login จะมีข้อเสีย เช่น
1) ง่ายต่อ hacker มาแอบลอบขี่ session
เพื่อสวมรอยใช้ sesion id (Cross-Site Request Forgery: CSRF)
…ทางเทคนิคขอไม่พูดถึง หาอ่านตามเว็บได้
2) เป็นภาระให้ server ต้องจำ session id ว่าเป็นของ user คนใด มีสิทธิอะไรบ้าง และจำข้อมูลอื่นๆ ของ user เป็นต้น
3) แล้วถ้าจะให้ user เดียวกัน login คนละอุปกรณ์ เช่น
เว็บก็ได้ มือถือก็ดี …จะยุ่งยากมากขึ้น (ต้องก็อปปี้ session ไปให้)
4) และข้อเสียอื่นๆ ทีไม่ได้กล่าวถึง

แต่เขาก็มีเทคนิคเพื่อแก้ทางนะครับ

ก็คือใช้สิ่งที่เรียกว่า “acces token ”
ซึ่งการที่จะได้ acces token
ก็ต้อง login ด้วย user/password เพื่อไปแลกเอามา
…ต้องยืนหมู ยืนแมวกันก่อน ถึงจะได้ access token
จากนั้นเราจะใช้มันแทนการ login ได้เลย

ทำให้เราไม่ต้องป้อน user/password บ่อยๆ
แล้วแต่ละ user ก็จะได้ access token หน้าตาไม่เหมือนกันเด็ดขาด
พอถึงเวลา user ทำการ logout ออกไป ตัว access token ก็จะหมดอายุทันที

ถึงตรงนี้ access token อาจเปรียบได้เหมือนกุญแจ
หรืออาจมองเป็นตั๋ว หรือบัตรผ่านก็ได้ …แล้วแต่จินตนาการเปรียบเปรย
ข้อแตกต่างจาก session id ก็คือ
1) access token จะไม่ถูกเก็บใน cookies
2) access token จะเก็บข้อมูล ที่พอเปิดเผยได้
เช่น user_id, สิทธิต่างๆ , วันหมดอายุ
(ไม่เป็นภาระให้ server จำข้อมูลพวกนี้)

ยิ่งถ้านำ access token ไปใช้งานร่วมกับกลไกล login ก็จะเห็นข้อดี เช่น
1) ป้องกัน hacker ไม่ให้แอบใช้ session ด้วยวิธี Cross-Site Request Forgery (CSRF)
2) สามารถ login จากมือถือ และเว็บ เพียงแค่ใช้ user เดียวกัน ก็ทำได้ง่ายดาย
ก็แค่แจก access token ให้แค่นั้น …ก็เหมือนที่ facebook ทำไง
(ไม่เก็บไว้ใน cookies ของ browser)
3) ตัว server สามารถทิ้งหน้าที่ login/logout อันเสียยุ่งยาก …โยนไปให้ authenticate service ข้างนอกทำแทน
4) ตัว server ไม่ต้องมีภาระดูแลข้อมูล user

ตัดกลับมาดูกลไก login ด้วย user/password ของ facebook
ซึ่งคอนเซปต์ตามรูปที่โพสต์เลยครับ (เป็นตัวอย่าง php)
สรุปง่ายๆ
– เวลา user ทำการ login
– มันจะแอบสวิซ์ไปหา facebook ให้ทำหน้าที่ login แทน
– เมื่อนั้น facebook จะโยน access token กลับมาให้เว็บเรา
– จากนั้น user จะใช้มันเป็นบัตรผ่าน ไม่ต้อง login ซ้ำอีกแหละ

ซึ่ง Access token ของเฟสบุ๊คมีหลายชนิด เช่น
-User Access Token
-App Access Token
-Page Access Token
-Client Token
แต่ละชนิดมีสิทธิแตกต่างกันได้ ขอไม่ลงลึกนะ

เรื่อง session id กับ access token ที่เล่ามาทั้งหมดนี้
ถือเป็นขอหวานอันแสนหอมที่ hacker ชอบมากๆ
ถ้าพวกเขาขโมยได้ รับรองว่าจะสวมรอย user ที่กำลัง login ได้
จากนั้น hacker จะได้สิทธิทุกอย่างเหมือน user นั้นหมด …เสร็จโจรละที่นี้

ยกเว้นเราจะ logout ออก
เพื่อให้ session id หรือ access token หมดอายุ
เมื่อนั้น hacker ก็จะหมดสิทธิสวมรอย

ในมุม user ก็แค่ล็อกอินใช้งานอย่างเดียว
ไม่ต้องสนใจ access token เบื้องหลังเลย
แต่ถ้าเป็น #โปรแกรมเมอร์ ต้องคำนึงถึงเป็นพิเศษ
เพราะขนาดสี่ตีนยังรู้พลาด นักปราชญ์ยังรู้พลั้ง
ยักษ์ใหญ่สุด พี่เบิ้มอย่าง facebook
ยังพลาดปล่อยให้ access token หลุดออกมาได้เลย จนเป็นข่าวสะเทือนใหญ่โต

ด้วยเหตุนี้การเขียนโปรแกรม
ก็ขอให้คำนึงถึงเรื่อง access token ห้ามหลุดรอด
ให้ปลอดภัยจาก hakcker เป็นดีที่สุด
โชคดีทุกท่านครับ

อ้างอิง
1) https://developers.facebook.com/docs/php/howto/example_facebook_login?locale=th_TH
2) https://developers.facebook.com/docs/facebook-login/access-tokens?locale=th_TH

เขียนโดยแอดมินโฮ โอน้อยออก

Please like Fanpage