Separating Identity and Delivery Channels for Compliant Telegram Mini App Authentication
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.
Related articles
Protecting Data Centers from Kinetic and Cyber Attacks: What Regulators Worldwide Are Proposing
InfoWatch experts have updated their April report on data center resilience, highlighting how physical and cyber threats now directly threaten business continuity and national security. Regulators in the United States, European Union, and Russia are treating data centers as strategic infrastructure requiring layered defenses that combine physical hardening, geographic distribution, and strict cybersecurity controls. The United States has launched the Cyberstrategy for America 2026 emphasizing offensive operations, Zero Trust modernization, and supply-chain restrictions. The European Union is implementing ProtectEU and the Cyber Solidarity Act with real-time threat sharing and mandatory resilience standards under DORA. Russia is advancing technological sovereignty targets, new siting rules for data centers, and Presidential Decree No. 604 that enables temporary state management of inadequately protected critical facilities. The report also notes growing recognition that attacks on data centers can constitute acts of aggression under the Tallinn Manual.
US Department of Homeland Security Orders Federal Agencies to Remove DeepSeek Products
The US Department of Homeland Security issued an order on October 19 requiring federal civilian agencies to cease purchasing products from DeepSeek and to remove related technology from government systems. The directive, published the following day, targets Hangzhou DeepSeek Artificial Intelligence, its affiliates, and any third-party products or services built on DeepSeek implementations. The measure stems from the Federal Acquisition Supply Chain Security Act of 2018 and follows a recommendation by the Federal Acquisition Security Council, though no specific incidents or evidence were detailed in the notice. The restriction applies only to federal environments and does not prohibit private sector or individual use outside government systems. No removal deadline was set, and the document does not name the signing authority. The order is filed under docket DHS-2026-0628 with the CISA implementation team listed as the contact point.
AKIT Requests Temporary Permission for Russian Companies to Transfer Personal Data Abroad After Data Center Incidents
The Association of Internet Trade Companies (AKIT) has sent a formal letter to Russian Prime Minister Mikhail Mishustin proposing a temporary exemption from strict data localization rules. The measure would allow affected companies to move critical systems and Russian citizens' personal data to data centers in friendly countries when domestic infrastructure is unavailable due to accidents or damage. Members including Ozon, Wildberries, Cooper, and Yandex Market argue that services must continue operating even if Russian facilities are compromised. The proposed special regime would apply only after an officially confirmed incident, require compliance with information security standards, and end no later than March 1, 2028. After recovery, companies would be required to return to normal data processing within Russia. Expert Alexey Muntyan noted that the mechanism activates only after incidents occur and questioned whether countries should be selected based on data protection levels rather than political alignment.
Anthropic Model Reconstructs NSA Seeds for NIST Elliptic Curves in Under 30 Minutes
An internal Anthropic research model traced the origins of the five seeds used by the NSA to generate the NIST elliptic curves P-192, P-224, P-256, P-384, and P-521. The discovery resolves a 25-year-old question that arose when the curves were standardized in FIPS 186-2 for ECDSA in 2000. Researchers combined analysis of 1990s random number generators, 34 generator-output combinations, and lattice reduction techniques to identify lrand48 initialized with Unix timestamps from May 1997 to April 1998. The P-256 seed corresponds to the 1842nd candidate from a run started on 16 August 1997, and example seeds from ANSI X9.62 follow the same pattern. The work does not demonstrate any cryptographic break or backdoor in the curves and does not recommend changes to production systems. Several questions remain open, including the seed for curve B-163 and the reason certain candidate values were discarded.