Telegram Access Token คืออะไร: Bot Token, API ID, API Hash และ Session String

หลายคนค้นหาคำว่า "Telegram access token" ราวกับว่า Telegram ออกกุญแจสากลให้เพียงดอกเดียว ซึ่งไม่ใช่ Telegram มีระบบยืนยันตัวตนหลายแบบ และข้อมูลรับรอง (credential) ที่ถูกต้องขึ้นอยู่กับว่าซอฟต์แวร์ของคุณกำลังควบคุมบอท อนุญาตการเข้าถึงบัญชีส่วนตัว ให้ผู้ใช้ล็อกอินเข้าเว็บไซต์ หรือเชื่อมต่อไคลเอนต์ที่ได้รับอนุญาตแล้วกลับเข้ามาใหม่

ความแตกต่างนี้สำคัญ เพราะข้อมูลรับรองแต่ละตัวมีอำนาจไม่เท่ากัน Bot Token ควบคุมบอทได้หนึ่งตัว API ID และ API Hash ใช้ระบุแอปพลิเคชันของนักพัฒนา รหัสล็อกอินพิสูจน์สิทธิ์เข้าถึงเบอร์โทรศัพท์แบบชั่วคราว ส่วน Session String หรือไฟล์เซสชันสามารถเก็บการอนุญาตบัญชีส่วนตัวที่ทำเสร็จแล้วเอาไว้ จึงอาจให้สิทธิ์เข้าถึงบัญชีได้โดยไม่ต้องล็อกอินซ้ำ การมองว่าค่าเหล่านี้ใช้แทนกันได้เป็นทั้งข้อผิดพลาดที่พบบ่อยในการพัฒนาและความเสี่ยงด้านความปลอดภัยที่ร้ายแรง

คู่มือนี้อธิบายว่าข้อมูลรับรองแต่ละตัวทำอะไร มาจากไหน และควรจัดการอย่างไรให้ปลอดภัย รวมถึงอธิบายว่าทำไมการเชื่อมต่อ Telegram CRM หรือ MCP สำหรับบัญชีส่วนตัวจึงไม่ใช่สิ่งเดียวกับการเชื่อมต่อผ่าน Bot API

ถ้าบทสอนไหนขอ "Telegram token" ให้หยุดก่อน แล้วดูให้ออกว่าหมายถึงแถวไหนในตารางนี้ ก่อนจะคัดลอกอะไรไปวาง

Bot Token ของ Telegram ใช้ยืนยันตัวตนของบอทกับ Bot API บทสอนการสร้างบอทอย่างเป็นทางการ ของ Telegram แนะนำให้นักพัฒนาสร้างบอทผ่าน @BotFather ซึ่งปกติใช้คำสั่ง /newbot จากนั้น BotFather จะส่งโทเค็นกลับมาให้ ระบบหลังบ้านจะใช้โทเค็นนี้เมื่อเรียกเมธอดอย่าง getMe, sendMessage หรือ setWebhook

โดยปกติ Bot Token จะมีหน้าตาเป็นตัวเลขระบุบอท ตามด้วยเครื่องหมายโคลอนและสตริงลับยาวๆ อย่าวางโทเค็นจริงลงในเอกสาร ภาพหน้าจอ ข้อความแชต ระบบติดตามปัญหา JavaScript ฝั่งไคลเอนต์ หรือ repository สาธารณะ Telegram แนะนำไว้ชัดเจนว่าให้ปฏิบัติต่อโทเค็นเหมือนรหัสผ่าน เพราะใครก็ตามที่ได้โทเค็นไปจะควบคุมบอทได้

Bot Token มีข้อจำกัดสำคัญ คือมันยืนยันตัวตนของบอท ไม่ใช่ตัวตน Telegram ส่วนตัวของคุณ บอทไม่สามารถเข้าไปอ่านกล่องข้อความส่วนตัวที่มีอยู่ของใครได้ง่ายๆ เอกสารเกี่ยวกับบอท ของ Telegram ยังอธิบายด้วยว่าบอทเริ่มบทสนทนากับผู้ใช้เองไม่ได้ ผู้ใช้ต้องติดต่อบอทก่อนหรือเพิ่มบอทเข้ากลุ่ม และในกลุ่ม การตั้งค่าความเป็นส่วนตัวยังจำกัดได้อีกว่าบอทจะได้รับข้อความใดบ้าง

เลือกใช้ Bot Token เมื่อคุณกำลังสร้างประสบการณ์แบบบอท เช่น คำสั่ง การแจ้งเตือน เมนู การรับเรื่องซัพพอร์ต Mini App หรือเวิร์กโฟลว์อัตโนมัติที่ผู้ใช้รู้ตัวว่ากำลังโต้ตอบกับบอท

ไคลเอนต์สำหรับบัญชีส่วนตัวใช้ MTProto API ของ Telegram แทนที่จะพึ่ง HTTP Bot API เพียงอย่างเดียว แอป Telegram ของบุคคลที่สามทุกตัวเป็นไคลเอนต์ประเภทนี้ ซึ่งเป็นเหตุผลที่การเลือกไคลเอนต์ Telegram สำหรับบัญชีที่ใช้ทำงานเป็นการตัดสินใจด้านความปลอดภัย ก่อนที่แอปพลิเคชันจะอนุญาตผู้ใช้ Telegram ได้ นักพัฒนาต้องมี API ID และ API Hash ก่อน

คำแนะนำการลงทะเบียนแอปพลิเคชันอย่างเป็นทางการ ของ Telegram อธิบายขั้นตอนไว้ดังนี้:

1. ใช้เบอร์โทรศัพท์ที่ลงทะเบียนกับ Telegram และยังใช้งานอยู่
2. ล็อกอินที่ my.telegram.org
3. เปิด API development tools (เครื่องมือพัฒนา API)
4. ลงทะเบียนแอปพลิเคชัน
5. เก็บ api_id และ api_hash ที่ได้มาไว้อย่างปลอดภัย

API ID คือตัวเลขระบุแอปพลิเคชัน ส่วน API Hash คือความลับที่จับคู่กัน ทั้งสองค่าใช้ระบุซอฟต์แวร์ที่ขอการอนุญาต แต่ลำพังตัวมันเองไม่ได้ทำให้ซอฟต์แวร์ล็อกอินเข้าบัญชี Telegram ทุกบัญชีได้ ยังต้องผ่านขั้นตอนการอนุญาตจากผู้ใช้อยู่ดี

อย่าคัดลอกข้อมูลรับรอง API จากโปรเจกต์ GitHub สุ่มๆ หรือแอปตัวอย่าง Telegram เตือนว่า API ID ตัวอย่างในโค้ดโอเพนซอร์สของตนมีข้อจำกัด และไม่เหมาะกับแอปพลิเคชันที่เปิดให้ผู้ใช้ใช้งานจริง การเชื่อมต่อระดับ production ควรใช้ข้อมูลรับรองที่ลงทะเบียนในนามขององค์กรที่ดำเนินการระบบนั้น และต้องปฏิบัติตามข้อกำหนด API ของ Telegram

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

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

อย่าส่งรหัสล็อกอิน Telegram ให้คนที่อ้างตัวว่าเป็นฝ่ายซัพพอร์ต อย่าวางรหัสลงในแชตกับบอท ถ้ามีใครขอรหัสล็อกอินนอกขั้นตอนการล็อกอิน นั่นคือสัญญาณเตือนที่ชัดเจนว่ามีคนพยายามยึดบัญชี

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

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

ให้ยึดกฎเหล่านี้:

• อย่า commit เซสชันลง Git
• อย่าใส่เซสชันไว้ในโค้ดฝั่งเบราว์เซอร์หรือระบบวิเคราะห์ข้อมูลของแอปมือถือ
• เข้ารหัสขณะจัดเก็บด้วยคีย์ที่มีระบบจัดการ ไม่ใช่คีย์ที่ hard-code ไว้ข้างๆ ข้อมูลที่เข้ารหัส
• จำกัดสิทธิ์เข้าถึงใน production ให้เหลือเฉพาะ service role ที่เล็กที่สุดเท่าที่ทำได้
• ปิดบังเซสชันออกจาก log และรายงานข้อผิดพลาด
• มีวิธีที่ชัดเจนให้ยกเลิกการเชื่อมต่อบัญชีและลบเซสชันที่เก็บไว้
• เพิกถอนเซสชันที่หลุดออกไปจากหน้าจอ Settings → Devices ของ Telegram และเปลี่ยนความลับอื่นที่เกี่ยวข้อง

Session String ไม่ใช่ Bot Token เวอร์ชันที่ปลอดภัยกว่า มันเป็นข้อมูลรับรองคนละประเภท และอาจมีสิทธิ์เข้าถึงกว้างกว่าด้วย

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

ใช้ Telegram Login เมื่อเป้าหมายคือ "ล็อกอินเข้าบริการของฉันด้วย Telegram" ใช้ Bot API เมื่อทำบอท และใช้ไคลเอนต์ MTProto ที่ได้รับอนุญาตเมื่อผลิตภัณฑ์จำเป็นต้องใช้ความสามารถของบัญชีส่วนตัวจริงๆ และมีโมเดลความยินยอมและความปลอดภัยที่ชัดเจน

MCP อธิบายวิธีที่ไคลเอนต์ AI ขอใช้เครื่องมือและการกระทำต่างๆ จากเซิร์ฟเวอร์ มันไม่ได้มาแทนการยืนยันตัวตนของ Telegram เซิร์ฟเวอร์ Telegram MCP ยังต้องมีชั้น Telegram ที่ได้รับอนุญาตอยู่เบื้องหลัง

ตัวอย่างเช่น Entergram เชื่อมบัญชี Telegram ส่วนตัวเข้ากับ workspace ผ่านขั้นตอนการอนุญาตที่ผู้ใช้อนุมัติเอง จากนั้นเซิร์ฟเวอร์ Telegram MCP แบบโฮสต์จะเปิดเครื่องมือ CRM และการส่งข้อความที่กำหนดไว้ให้ไคลเอนต์ MCP ที่ได้รับอนุมัติ ไคลเอนต์ AI ได้รับสิทธิ์ใช้เครื่องมือ แต่ไม่ควรได้รับรหัสล็อกอิน Telegram, API Hash หรือเซสชันบัญชีที่นำกลับมาใช้ซ้ำได้แบบดิบๆ

การแยกส่วนแบบนี้คือสถาปัตยกรรมที่ปลอดภัยกว่า:

1. ข้อมูลรับรอง Telegram อยู่ภายในบริการที่รับผิดชอบการอนุญาต Telegram
2. เซิร์ฟเวอร์ MCP เปิดเฉพาะการทำงานที่กำหนดไว้อย่างแคบ
3. OAuth และสิทธิ์ของ workspace เป็นตัวกำหนดว่าบุคคลหรือไคลเอนต์ AI ใดเรียกใช้การทำงานเหล่านั้นได้
4. Audit log บันทึกการกระทำทางธุรกิจ โดยไม่บันทึกความลับที่ใช้ยืนยันตัวตน
5. การเพิกถอนสิทธิ์สามารถปิดไคลเอนต์ MCP ได้ โดยไม่บังคับให้ผู้ใช้ต้องเปิดเผยหรือเปลี่ยนข้อมูลรับรอง Telegram เบื้องหลังทุกตัว

อ่านเปรียบเทียบ Telegram MCP กับ Bot API เพื่อดูความแตกต่างด้านความสามารถ

ก่อนเปิดใช้งานการเชื่อมต่อ Telegram ใดๆ ให้ตอบคำถามเหล่านี้:

• การเชื่อมต่อนี้ทำงานในฐานะบอทหรือบัญชีส่วนตัว?
• จริงๆ แล้วต้องใช้แชตและการกระทำใดบ้าง?
• ผู้ใช้สามารถยกเว้นบทสนทนาส่วนตัวหรือบางบัญชีได้หรือไม่?
• การกระทำที่เขียนข้อมูลแยกออกจากการกระทำแบบอ่านอย่างเดียวหรือไม่?

• Bot Token, API Hash และเซสชันถูกเก็บไว้บนเซิร์ฟเวอร์ที่เชื่อถือได้เท่านั้นหรือไม่?
• ความลับถูกเข้ารหัสขณะจัดเก็บและได้รับการปกป้องระหว่างส่งหรือไม่?
• ข้อมูลรับรอง production ถูกกันออกจาก source control และ preview deployment หรือไม่?
• ระบบ log ระบบ tracing และเครื่องมือซัพพอร์ตลูกค้าถูกตั้งค่าให้ปิดบังความลับเหล่านี้หรือไม่?

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

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

เรียกข้อมูลรับรองทุกตัวว่าโทเค็น ทำให้วิศวกรใส่ค่าผิดลงในช่องผิด และทำให้การตรวจสอบความปลอดภัยคลุมเครือ ตั้งชื่อตัวแปรการตั้งค่าให้แม่นยำ: TELEGRAM_BOT_TOKEN, TELEGRAM_API_ID และ TELEGRAM_API_HASH ชัดเจนกว่า TELEGRAM_TOKEN

ใส่ Bot Token ไว้ในโค้ดฝั่ง frontend อะไรก็ตามที่ส่งไปถึงเบราว์เซอร์ควรถือว่าเป็นข้อมูลสาธารณะ ให้ส่งการเรียก Bot API ผ่านระบบหลังบ้านที่มีการป้องกัน

คิดว่า API ID และ API Hash เท่ากับสิทธิ์เข้าถึงบัญชี สองค่านี้ใช้ระบุแอปพลิเคชัน ผู้ใช้ยังต้องอนุญาตบัญชีอยู่ดี

มองว่าเซสชันเป็นแค่แคชที่ไม่มีพิษภัย เซสชันคือข้อมูลสำหรับยืนยันตัวตน ต้องปกป้องเหมือนข้อมูลรับรองและต้องเพิกถอนได้

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

สรุปคือ Telegram ไม่ได้มี access token ตัวเดียวที่ใช้ได้กับทุกอย่าง ถ้าคุณต้องการสร้างบอท Telegram ให้สร้างผ่าน BotFather และใช้ Bot Token บนระบบหลังบ้านของคุณ ถ้าคุณกำลังพัฒนาไคลเอนต์ Telegram ที่ได้รับอนุญาตสำหรับบัญชีส่วนตัว ให้ลงทะเบียน API ID และ API Hash ของคุณเอง จากนั้นทำขั้นตอนการอนุญาตผู้ใช้ของ Telegram ให้เสร็จ และปกป้องเซสชันที่ได้มา ถ้าคุณต้องการแค่ระบบล็อกอิน ให้ใช้ Telegram Login แทนการขอสิทธิ์เข้าถึงกล่องข้อความ

สำหรับทีมที่ต้องการให้เครื่องมือ AI ทำงานกับบัญชี Telegram ส่วนตัวที่ได้รับอนุมัติ เซิร์ฟเวอร์ Telegram MCP ที่มีระบบสิทธิ์จะช่วยให้ไม่ต้องส่งข้อมูลรับรอง Telegram แบบดิบเข้าไปในไคลเอนต์ AI ทุกตัว ไม่ว่าคุณจะเลือกทางไหน อย่าให้ความลับที่ใช้ยืนยันตัวตนหลุดไปอยู่ใน prompt, repository, โค้ดฝั่งเบราว์เซอร์ หรือภาพหน้าจอ และออกแบบให้เพิกถอนสิทธิ์ได้ตั้งแต่วันแรก