When configuring authorization in Telegram Mini Apps, the initial flow appears straightforward: Telegram supplies initData, the server validates the HMAC-SHA-256 signature derived from the bot token, and everything works out of the box. However, services aimed at Russian users must also satisfy stricter identification requirements, prompting the team to keep Telegram primarily as a delivery channel rather than the sole login method.
The architecture explicitly separates two concepts: “who the user is” (identity) and “where to send notifications” (channel identity). Users authenticate via VK ID, Yandex ID or MAX, after which their telegram_id is linked to the account solely for message delivery. The database schema reflects this split with separate tables storing max_user_id, vk_user_id, yandex_id for identity and max_chat_id, vk_chat_id, telegram_id for delivery channels.
Three buttons labeled MAX, VK and Yandex appear inside the mini-app; no “Login with Telegram” option exists. For VK ID the team uses OAuth 2.1 with PKCE: the browser generates a code_verifier, computes the S256 code_challenge, and includes both state and challenge in the authorization request. The server stores the verifier keyed by state for later validation.
Authorization opens in a new browser tab, allowing users to complete the flow in their main browser even when the mini-app runs inside Telegram WebView or on another device. After success the tab closes itself and the main interface learns the outcome via polling. The same pattern was applied to smart-home authorization through Home Assistant.
Yandex authentication follows a similar OAuth 2.0 flow, but the authorization URL is generated on the backend. The server exchanges the received code for an access token, retrieves the user identifier, and returns the result via a /api/auth/result-by-state endpoint that clients poll (for example, 120 attempts at three-second intervals). Only a short-lived application-level code travels to the browser; the OAuth token itself never reaches client JavaScript and is instead stored in an HttpOnly cookie, reducing XSS exposure.
State values are generated with crypto.randomUUID() or crypto.getRandomValues() providing at least 128 bits of entropy and are stored server-side with a short TTL. The callback avoids placing any auth_token in the URL; a one-time code is exchanged for a session via POST. A from_extension flag is passed only for UI adjustments and carries no security meaning on the server.
MAX integration uses a deep link containing a single-use token; after binding, the bot posts a confirmation message in the chat. Consent handling differs by platform: Telegram WebApp versions display two checkboxes (general consent and separate consent for data transfer to Telegram) to meet legal requirements, while the PWA version requires only one checkbox.
The resulting system powers the project “My Anti-Social Network,” an ad-free news aggregator that includes bots in Telegram, MAX and VK, a PWA, browser extensions, mobile apps and integrations with smart-home and voice assistants. The developer notes that while the technical pattern supports compliance, final legal validity depends on specific regulatory interpretation.
