Giải thích Telegram access token: bot token, API ID, API hash và session string

Nhiều người tìm “Telegram access token” như thể Telegram cấp một chìa khóa dùng chung cho mọi việc. Thực tế không phải vậy. Telegram có nhiều hệ thống xác thực, và thông tin xác thực đúng phụ thuộc vào việc phần mềm của bạn đang điều khiển một bot, cấp quyền cho một tài khoản cá nhân, đăng nhập người dùng vào một website, hay kết nối lại một client đã được cấp quyền.

Sự khác biệt này quan trọng vì mỗi loại có quyền hạn khác nhau. Bot token điều khiển một bot. API ID và API hash định danh một ứng dụng của nhà phát triển. Mã đăng nhập chứng minh quyền truy cập tạm thời vào một số điện thoại. Session string hoặc session file có thể lưu lại một lần cấp quyền tài khoản cá nhân đã hoàn tất, vì vậy có thể cho phép truy cập tài khoản mà không cần đăng nhập lại. Coi các giá trị này là có thể thay thế cho nhau vừa là lỗi triển khai phổ biến, vừa là rủi ro bảo mật nghiêm trọng.

Bài hướng dẫn này giải thích từng loại thông tin xác thực làm gì, lấy từ đâu và cách xử lý an toàn. Bài cũng giải thích vì sao kết nối Telegram CRM hoặc MCP cho tài khoản cá nhân không giống một tích hợp Bot API.

Nếu một hướng dẫn yêu cầu “Telegram token”, hãy dừng lại và xác định nó đang nói đến dòng nào trước khi sao chép bất cứ thứ gì.

Bot token xác thực một bot với Bot API. Hướng dẫn bot chính thức của Telegram yêu cầu nhà phát triển tạo bot qua @BotFather, thường bằng lệnh /newbot. BotFather trả về một token mà backend dùng khi gọi các phương thức như getMe, sendMessage hoặc setWebhook.

Bot token thường có dạng một mã định danh bot bằng số, tiếp theo là dấu hai chấm và một chuỗi bí mật dài. Đừng dán token thật vào tài liệu, ảnh chụp màn hình, tin nhắn chat, hệ thống theo dõi issue, JavaScript phía client hoặc repository công khai. Telegram khuyến cáo rõ ràng rằng bạn nên coi token như mật khẩu, vì bất kỳ ai có nó đều điều khiển được bot.

Bot token có một giới hạn quan trọng: nó xác thực danh tính của bot, không phải danh tính Telegram cá nhân của bạn. Bot không thể đơn giản đọc hộp thư riêng hiện có của một người. Tài liệu về bot của Telegram cũng giải thích rằng bot không thể chủ động bắt đầu cuộc trò chuyện với người dùng; người dùng phải liên hệ bot trước hoặc thêm bot vào nhóm. Trong nhóm, cài đặt quyền riêng tư còn có thể giới hạn thêm những tin nhắn bot nhận được.

Hãy chọn bot token khi bạn xây dựng trải nghiệm dạng bot: lệnh, thông báo, menu, tiếp nhận yêu cầu hỗ trợ, Mini App hoặc quy trình tự động mà người dùng biết rõ họ đang tương tác với bot.

Client cho tài khoản cá nhân dùng MTProto API của Telegram thay vì chỉ dựa vào HTTP Bot API. Mọi ứng dụng Telegram bên thứ ba đều thuộc loại này, đó là lý do chọn một Telegram client cho tài khoản công việc là một quyết định về bảo mật. Trước khi một ứng dụng có thể cấp quyền cho người dùng Telegram, nhà phát triển cần có API ID và API hash.

Hướng dẫn đăng ký ứng dụng chính thức của Telegram mô tả quy trình:

1. Dùng một số điện thoại đang hoạt động đã đăng ký Telegram.
2. Đăng nhập tại my.telegram.org.
3. Mở API development tools (công cụ phát triển API).
4. Đăng ký ứng dụng.
5. Lưu trữ api_id và api_hash nhận được một cách an toàn.

API ID là mã định danh ứng dụng dạng số. API hash là khóa bí mật đi kèm. Chúng định danh phần mềm đang yêu cầu cấp quyền; tự chúng không đăng nhập phần mềm vào mọi tài khoản Telegram. Vẫn cần một quy trình cấp quyền của người dùng.

Đừng sao chép thông tin xác thực API từ một dự án GitHub ngẫu nhiên hay ứng dụng mẫu. Telegram cảnh báo rằng API ID mẫu trong mã nguồn mở của họ bị giới hạn và không phù hợp cho ứng dụng phát hành tới người dùng. Một tích hợp chạy production nên dùng thông tin xác thực đăng ký cho chính tổ chức vận hành nó và tuân thủ điều khoản API của Telegram.

Khi một client MTProto cấp quyền cho tài khoản cá nhân, Telegram thường gửi mã đăng nhập tạm thời qua một phiên Telegram hiện có hoặc một kênh được hỗ trợ khác. Nếu tài khoản bật xác minh hai bước, Telegram sẽ hỏi thêm mật khẩu bổ sung của tài khoản.

Cả hai giá trị này đều không phải thông tin xác thực API mà nhà phát triển nên lưu vĩnh viễn. Mã đăng nhập là bằng chứng tạm thời rằng người kiểm soát tài khoản đồng ý cho đăng nhập. Mật khẩu xác minh hai bước là mật khẩu của chủ tài khoản. Một màn hình cấp quyền hợp lệ cần giải thích vì sao cần giá trị đó, truyền nó một cách an toàn và không ghi nó vào log hay hệ thống phân tích.

Không bao giờ gửi mã đăng nhập Telegram cho người tự xưng là bộ phận hỗ trợ. Không bao giờ dán mã vào cuộc trò chuyện với bot. Một yêu cầu cung cấp mã đăng nhập bên ngoài quy trình đăng nhập là dấu hiệu cảnh báo mạnh về việc chiếm đoạt tài khoản.

Sau khi cấp quyền thành công, các thư viện MTProto thường lưu lại một phiên (session). Tùy thư viện, phiên đó có thể được lưu trong một file cơ sở dữ liệu cục bộ, một bản ghi đã mã hóa hoặc một chuỗi có thể mang đi.

Session giúp người dùng không phải nhập mã đăng nhập mới mỗi lần ứng dụng khởi động lại. Chính sự tiện lợi đó khiến nó cực kỳ nhạy cảm. Một session hợp lệ có thể tương đương một thiết bị đã được cấp quyền, nên nếu bị lộ, bên khác có thể thao tác thông qua tài khoản cho đến khi session bị thu hồi.

Hãy áp dụng các quy tắc sau:

• Không bao giờ commit session lên Git.
• Không bao giờ đưa session vào mã trình duyệt hoặc hệ thống phân tích trên di động.
• Mã hóa session khi lưu trữ bằng khóa được quản lý, không dùng khóa viết cứng nằm cạnh dữ liệu đã mã hóa.
• Giới hạn quyền truy cập trên production ở vai trò dịch vụ nhỏ nhất có thể.
• Che session khỏi log và báo cáo lỗi.
• Cung cấp cách rõ ràng để ngắt kết nối tài khoản và xóa session đã lưu.
• Thu hồi session bị lộ từ màn hình Settings → Devices (Cài đặt, Thiết bị) của Telegram và thay mới các khóa bí mật liên quan.

Session string không phải là phiên bản an toàn hơn của bot token. Đó là một loại thông tin xác thực khác, với quyền truy cập có thể rộng hơn nhiều.

Telegram cũng hỗ trợ đăng nhập vào website và ứng dụng qua Telegram Login, chính là “Telegram login API” mà phần lớn hướng dẫn nhắc tới, bao gồm cả quy trình OpenID Connect. Quy trình này xác thực người dùng Telegram với một ứng dụng khác và trả về thông tin định danh đã ký hoặc token có phạm vi giới hạn. Nó không tự động cấp quyền đọc hộp thư Telegram cá nhân của người dùng.

Dùng Telegram Login khi mục tiêu là “đăng nhập vào dịch vụ của tôi bằng Telegram”. Dùng Bot API cho bot. Dùng client MTProto đã được cấp quyền khi sản phẩm thực sự cần tính năng của tài khoản cá nhân và có mô hình đồng ý cũng như bảo mật rõ ràng.

MCP mô tả cách một AI client yêu cầu công cụ và hành động từ một server. Nó không thay thế xác thực Telegram. Một Telegram MCP server vẫn cần một lớp Telegram đã được cấp quyền phía sau.

Ví dụ, Entergram kết nối tài khoản Telegram cá nhân vào workspace thông qua quy trình cấp quyền do người dùng phê duyệt. Sau đó, Telegram MCP server được lưu trữ sẵn sẽ cung cấp các công cụ CRM và nhắn tin đã định nghĩa cho một MCP client được phê duyệt. AI client nhận quyền dùng công cụ; nó không nên nhận mã đăng nhập Telegram thô, API hash hay session tài khoản có thể tái sử dụng.

Cách tách biệt này là kiến trúc an toàn hơn:

1. Thông tin xác thực Telegram nằm trong dịch vụ chịu trách nhiệm cấp quyền Telegram.
2. MCP server chỉ cung cấp các thao tác được định nghĩa hẹp.
3. OAuth và quyền trong workspace quyết định người nào hoặc AI client nào được gọi các thao tác đó.
4. Audit log ghi lại các hành động nghiệp vụ mà không ghi lại khóa bí mật xác thực.
5. Việc thu hồi có thể vô hiệu hóa MCP client mà không buộc người dùng phải để lộ hoặc thay mới mọi thông tin xác thực Telegram bên dưới.

Đọc bài Telegram MCP so với Bot API để hiểu sự khác biệt về khả năng.

Trước khi phát hành bất kỳ tích hợp Telegram nào, hãy trả lời các câu hỏi sau:

• Tích hợp hoạt động dưới danh nghĩa bot hay tài khoản cá nhân?
• Nó thực sự cần những chat và hành động nào?
• Người dùng có thể loại trừ các cuộc trò chuyện riêng tư hoặc tài khoản nhất định không?
• Hành động ghi có được tách riêng khỏi hành động chỉ đọc không?

• Bot token, API hash và session có chỉ được lưu trên server tin cậy không?
• Khóa bí mật có được mã hóa khi lưu trữ và được bảo vệ khi truyền tải không?
• Thông tin xác thực production có được loại khỏi hệ thống quản lý mã nguồn và các bản deploy preview không?
• Log, hệ thống tracing và công cụ hỗ trợ khách hàng có được cấu hình để che chúng không?

• Mỗi tài khoản đã kết nối có chủ sở hữu xác định được không?
• Quản trị viên có thể ngắt kết nối một tài khoản mà không ảnh hưởng đến các tài khoản khác không?
• Quyền truy cập của từng AI client hoặc nhân viên có thể bị thu hồi độc lập không?
• Các hành động đặc quyền có được ghi lại kèm người thực hiện, thời gian, tài khoản và kết quả không?

• Có quy trình được ghi lại để thay mới bot token không?
• Đội ngũ có thể vô hiệu hóa nhanh một session bị đánh cắp không?
• Dịch vụ có cảnh báo khi có vị trí đăng nhập bất thường hoặc hành động số lượng lớn không?
• Bản sao lưu có được mã hóa và áp dụng cùng chính sách xóa không?

Gọi mọi thông tin xác thực là token. Điều này khiến kỹ sư điền sai giá trị vào sai trường và làm việc rà soát bảo mật trở nên mơ hồ. Hãy đặt tên biến cấu hình thật chính xác: TELEGRAM_BOT_TOKEN, TELEGRAM_API_ID và TELEGRAM_API_HASH rõ ràng hơn TELEGRAM_TOKEN.

Đặt bot token trong mã frontend. Mọi thứ gửi tới trình duyệt đều nên được coi là công khai. Hãy chuyển các lệnh gọi Bot API qua một backend được bảo vệ.

Cho rằng API ID và API hash đồng nghĩa với quyền truy cập tài khoản. Chúng chỉ định danh ứng dụng. Người dùng vẫn cần cấp quyền cho tài khoản.

Coi session là bộ nhớ đệm vô hại. Session là dữ liệu xác thực. Hãy bảo vệ nó như một thông tin xác thực và đảm bảo có thể thu hồi.

Thu thập nhiều quyền hơn mức quy trình cần. Bot thông báo không cần session tài khoản cá nhân. Quy trình báo cáo có thể không cần quyền gửi tin nhắn. Hãy bắt đầu với thiết kế hẹp nhất mà vẫn hoạt động được.

Tóm lại, Telegram không cấp một access token duy nhất cho mọi việc. Nếu bạn muốn xây dựng bot Telegram, hãy tạo bot bằng BotFather và dùng bot token của nó trên backend. Nếu bạn đang phát triển một Telegram client được cấp quyền cho tài khoản cá nhân, hãy đăng ký API ID và API hash của riêng bạn, sau đó hoàn tất quy trình cấp quyền người dùng của Telegram và bảo vệ session tạo ra. Nếu bạn chỉ cần tính năng đăng nhập, hãy dùng Telegram Login thay vì yêu cầu quyền truy cập hộp thư.

Với những đội muốn công cụ AI làm việc với các tài khoản Telegram cá nhân đã được phê duyệt, một Telegram MCP server có phân quyền giúp tránh việc chuyển thông tin xác thực Telegram thô vào từng AI client. Dù chọn cách nào, hãy giữ khóa bí mật xác thực ngoài prompt, repository, mã trình duyệt và ảnh chụp màn hình, đồng thời đưa khả năng thu hồi vào thiết kế ngay từ ngày đầu.