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
Encrypt Don't Trust: Securing Palm Vein Biometrics from Sensor to Access Control Server
An in-depth technical analysis explores how to protect palm vein biometric data in access control systems using a security-by-design approach. The article emphasizes that biometric templates cannot be changed like passwords, making robust protection essential against physical theft, insider threats, and presentation attacks. It details the application of Zero Trust principles, minimizing the Trusted Computing Base, and implementing hardware roots of trust such as Secure Boot and encrypted non-volatile memory. Russian regulatory requirements including 152-FZ, Government Decree No. 1119 for data protection levels, FSTEC Order No. 21, and FSB Order No. 378 are mapped directly to technical controls like mTLS, OSDP v2.2, and liveness detection. Threat actor profiles ranging from external attackers to privileged insiders are analyzed with specific countermeasures for each segment of the data path. The piece concludes that trust must be compressed to the hardware root, server room, and dual-operator registration process while everything else relies on verifiable cryptography and auditing.
25-Year Mystery Solved: NIST Elliptic Curve Seeds Came from lrand48 and Unix Timestamps
Researchers at Anthropic used the Claude model to trace the origins of the mysterious seed values embedded in NIST elliptic curves standardized in FIPS 186-2. The seeds for curves including NIST P-192, P-224, P-256, P-384 and P-521 were not derived from hashed humorous phrases as previously rumored but instead generated by the non-cryptographic lrand48 linear congruential generator seeded with Unix timestamps from 1997 and 1998. The discovery also explains the base points of several curves using the FreeLIP library's random number generator. The findings reduce long-standing suspicions of deliberate backdoors inserted by the NSA. Several candidate curves that met the criteria were skipped during selection, leaving open questions about the exact filtering process. The work was performed by a team including Nicholas Carlini and others, with the reproduction code released into the public domain.
Japan's IPA Opens Special Consultation Desk for Suspected Cyberattack Data Leaks
The Information-technology Promotion Agency (IPA) has launched a dedicated Unauthorized Access Special Consultation Desk to assist companies and organizations affected by cyber attacks resulting in information leaks. The service accepts inquiries from entities that only suspect they may have been victimized, providing initial response guidance even before confirmed incidents. Consultations cover advice on whether unauthorized access or data exfiltration is likely, recommended immediate containment steps, lists of incident response vendors, and reporting obligations to relevant authorities. The hotline operates on weekdays from 9:30 to 17:30 excluding the lunch hour, while email replies may take until the next business day. Separate channels exist for non-access incidents, general security advice, and individual personal data breach concerns. The move responds to a rising number of breaches targeting online services handling personal information.
Russian State Duma Approves Outsourcing of Banking Secrecy and Client Data Without Consent
The State Duma has passed legislation in its second and third readings permitting Russian banks to transfer client data processing, including banking secrecy and personal information, to external IT contractors and cloud providers. No separate client consent will be required for such transfers. Only accredited Russian IT companies and banks holding a universal license that meet strict domestic control criteria may act as processors, with all servers required to remain inside Russia. Banks must notify the Central Bank of Russia in advance, and contractors must undergo audits by organizations licensed by FSTEC or FSB Russia. Special approval procedures involving the Central Bank, FSB, and Rosfinmonitoring apply to banks under foreign control. The law preserves banking secrecy while expanding the circle of authorized handlers under defined security obligations.