Telegram access token בהסבר פשוט: bot token, API ID, API hash ו-session string

אנשים מחפשים לא פעם "Telegram access token" כאילו Telegram מנפיק מפתח אוניברסלי אחד. זה לא המצב. ל-Telegram יש כמה מערכות אימות, ופרט ההתחברות הנכון תלוי במה שהתוכנה שלכם עושה: שולטת בבוט, מאשרת חשבון אישי, מחברת משתמש לאתר, או מתחברת מחדש עם לקוח שכבר אושר.

ההבחנה חשובה כי לפרטי ההתחברות יש סמכויות שונות. bot token שולט בבוט אחד. API ID ו-API hash מזהים אפליקציה של מפתח. קוד התחברות מוכיח גישה זמנית למספר טלפון. session string או קובץ סשן יכולים לשמר הרשאה שהושלמה לחשבון אישי, ולכן עשויים לתת גישה לחשבון בלי בקשת התחברות נוספת. להתייחס לערכים האלה כאילו הם ניתנים להחלפה זו גם טעות מימוש נפוצה וגם סיכון אבטחה רציני.

המדריך הזה מסביר מה כל פרט התחברות עושה, מאיפה הוא מגיע ואיך לטפל בו בבטחה. הוא גם מסביר למה CRM ל-Telegram או חיבור MCP לחשבונות אישיים הם לא אותו דבר כמו אינטגרציה עם Bot API.

אם מדריך כלשהו מבקש "Telegram token", עצרו וזהו לאיזו שורה הוא מתכוון לפני שאתם מעתיקים משהו.

bot token של Telegram מאמת בוט מול ה-Bot API. המדריך הרשמי של Telegram לבוטים מנחה מפתחים ליצור בוט דרך @BotFather, בדרך כלל עם הפקודה /newbot. BotFather מחזיר טוקן שהבקאנד משתמש בו כשהוא קורא למתודות כמו getMe, sendMessage או setWebhook.

bot token נראה בדרך כלל כמו מזהה בוט מספרי, ואחריו נקודתיים וסוד ארוך. אל תדביקו טוקן אמיתי בתיעוד, בצילומי מסך, בהודעות צ'אט, במערכות מעקב תקלות, ב-JavaScript בצד הלקוח או במאגר ציבורי. Telegram ממליץ במפורש להתייחס לטוקן כמו לסיסמה, כי כל מי שמחזיק בו יכול לשלוט בבוט.

ל-bot tokens יש מגבלה חשובה: הם מאמתים את זהות הבוט, לא את זהות ה-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 לדוגמה בקוד הפתוח שלו מוגבל ולא מתאים לאפליקציות שמופצות למשתמשים. אינטגרציה בסביבת ייצור צריכה להשתמש בפרטים שרשומים על שם הארגון שמפעיל אותה ולעמוד בתנאי ה-API של Telegram.

כשלקוח MTProto מאשר חשבון אישי, Telegram שולח בדרך כלל קוד התחברות זמני דרך סשן Telegram קיים או ערוץ נתמך אחר. אם בחשבון מופעל אימות דו-שלבי, Telegram מבקש גם את הסיסמה הנוספת של החשבון.

אף אחד מהערכים האלה הוא לא פרט API שמפתח צריך לשמור לצמיתות. הקוד הוא הוכחה זמנית לכך שמי ששולט בחשבון מאשר את ההתחברות. סיסמת האימות הדו-שלבי היא הסיסמה של בעל החשבון. מסך הרשאה לגיטימי צריך להסביר למה הערך נדרש, להעביר אותו בצורה מאובטחת ולא לרשום אותו בלוגים או באנליטיקה.

לעולם אל תשלחו קוד התחברות של Telegram למישהו שמציג את עצמו כתמיכה. לעולם אל תדביקו קוד כזה בשיחה עם בוט. בקשה לקוד התחברות מחוץ לתהליך התחברות היא סימן אזהרה חזק להשתלטות על חשבון.

אחרי הרשאה מוצלחת, ספריות MTProto בדרך כלל שומרות סשן. בהתאם לספרייה, הסשן יכול להישמר בקובץ מסד נתונים מקומי, ברשומה מוצפנת או במחרוזת ניידת.

הסשן חוסך מהמשתמשים להזין קוד התחברות חדש בכל פעם שהאפליקציה מופעלת מחדש. הנוחות הזו היא בדיוק מה שהופך אותו לרגיש מאוד. סשן תקף יכול לייצג מכשיר שכבר אושר, ולכן חשיפה שלו עלולה לאפשר לגורם אחר לפעול דרך החשבון עד שהסשן מבוטל.

השתמשו בכללים האלה:

• לעולם אל תעשו commit לסשנים ב-Git.
• לעולם אל תכללו אותם בקוד דפדפן או באנליטיקה של מובייל.
• הצפינו אותם במנוחה עם מפתח מנוהל, לא עם מפתח קשיח שיושב ליד הטקסט המוצפן.
• הגבילו את הגישה בסביבת הייצור לתפקיד השירות המצומצם ביותר האפשרי.
• הסתירו אותם מלוגים ומדוחות שגיאה.
• ספקו דרך ברורה לנתק את החשבון ולמחוק את הסשן השמור.
• בטלו סשן שנחשף ממסך 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 אישיים לסביבת עבודה דרך תהליך הרשאה שהמשתמש מאשר. שרת ה-Telegram MCP המתארח חושף אז כלי CRM ומסרים מוגדרים ללקוח MCP מאושר. לקוח ה-AI מקבל גישה לכלים; הוא לא אמור לקבל קודי התחברות גולמיים של Telegram, API hashes או סשנים של חשבון שאפשר לעשות בהם שימוש חוזר.

ההפרדה הזו היא הארכיטקטורה הבטוחה יותר:

1. פרטי ההתחברות של Telegram נשארים בתוך השירות שאחראי על הרשאת Telegram.
2. שרת ה-MCP חושף פעולות מוגדרות בצמצום.
3. OAuth והרשאות סביבת העבודה קובעים איזה אדם או לקוח AI רשאי לקרוא לפעולות האלה.
4. לוגי ביקורת רושמים פעולות עסקיות בלי לרשום סודות אימות.
5. ביטול גישה יכול להשבית את לקוח ה-MCP בלי לחייב את המשתמש לחשוף או להחליף כל פרט התחברות של Telegram שמתחתיו.

קראו את Telegram MCP מול Bot API כדי להבין את ההבדלים ביכולות.

לפני שאתם משיקים אינטגרציה כלשהי עם Telegram, ענו על השאלות האלה:

• האם האינטגרציה פועלת כבוט או כחשבון אישי?
• לאילו צ'אטים ופעולות היא באמת זקוקה?
• האם המשתמש יכול להחריג שיחות פרטיות או חשבונות?
• האם פעולות כתיבה מופרדות מפעולות קריאה בלבד?

• האם bot tokens, API hashes וסשנים נשמרים רק בשרתים מהימנים?
• האם הסודות מוצפנים במנוחה ומוגנים בתעבורה?
• האם פרטי ההתחברות של הייצור מוחרגים מניהול הקוד ומפריסות preview?
• האם הלוגים, מערכות ה-tracing וכלי תמיכת הלקוחות מוגדרים להסתיר אותם?

• האם לכל חשבון מחובר יש בעלים מזוהה?
• האם מנהל יכול לנתק חשבון אחד בלי להשפיע על אחרים?
• האם אפשר לבטל גישה ללקוח AI אחד או לעובד אחד באופן עצמאי?
• האם פעולות מורשות נרשמות עם המבצע, הזמן, החשבון והתוצאה?

• האם יש נוהל מתועד להחלפת bot token?
• האם הצוות יכול לבטל במהירות סשן גנוב?
• האם השירות מתריע על מיקומי התחברות חריגים או על פעולות בהיקף גבוה?
• האם הגיבויים מוצפנים וכפופים לאותה מדיניות מחיקה?

לקרוא לכל פרט התחברות "טוקן". זה מוביל מהנדסים לשים את הערך הלא נכון בשדה הלא נכון והופך סקירות אבטחה לעמומות. תנו למשתני ההגדרות שמות מדויקים: TELEGRAM_BOT_TOKEN, TELEGRAM_API_ID ו-TELEGRAM_API_HASH ברורים יותר מ-TELEGRAM_TOKEN.

לשים bot token בקוד הפרונטאנד. כל מה שמגיע לדפדפן צריך להיחשב ציבורי. נתבו קריאות ל-Bot API דרך בקאנד מוגן.

להניח ש-API ID ו-API hash שווים לגישה לחשבון. הם מזהים את האפליקציה. המשתמש עדיין צריך לאשר את החשבון.

להתייחס לסשן כאל מטמון לא מזיק. סשן הוא חומר אימות. הגנו עליו כמו על פרט התחברות, ודאגו שאפשר יהיה לבטל אותו.

לאסוף יותר גישה ממה שתהליך העבודה צריך. בוט התראות לא צריך סשן של חשבון אישי. תהליך דיווח אולי לא צריך הרשאה לשליחת הודעות. התחילו מהתכנון המצומצם ביותר שעובד.

אז אין access token יחיד ש-Telegram מנפיק לכל דבר. אם אתם רוצים לבנות בוט Telegram, צרו אותו עם BotFather והשתמשו ב-bot token שלו בבקאנד. אם אתם מפתחים לקוח Telegram מאושר לחשבונות אישיים, רשמו API ID ו-API hash משלכם, השלימו את תהליך הרשאת המשתמש של Telegram והגנו על הסשן שנוצר. אם אתם צריכים רק התחברות, השתמשו ב-Telegram Login במקום לבקש גישה לתיבת ההודעות.

לצוותים שרוצים שכלי AI יעבדו עם חשבונות Telegram אישיים מאושרים, שרת Telegram MCP עם הרשאות חוסך את הצורך להעביר פרטי התחברות גולמיים של Telegram לכל לקוח AI. בכל דרך שתבחרו, השאירו את סודות האימות מחוץ לפרומפטים, למאגרי קוד, לקוד הדפדפן ולצילומי המסך, והפכו את ביטול הגישה לחלק מהתכנון כבר מהיום הראשון.