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
FSTEC Publishes 35-Point Network Perimeter Recommendations, Most Require No Spending
Russia's FSTEC released non-binding recommendations on protecting network perimeters on March 10, 2026, analyzing real-world intrusion vectors from external networks. The 35-point checklist spans eight sections covering device administration, DDoS resilience, segmentation, configuration backups, vulnerability management, authentication, logging, and incident response exercises. Only four items explicitly require purchasing new tools such as WAF, ZTNA, NAC, and SIEM, while five others depend on existing infrastructure. Twenty-six points can be addressed through policy, inventory, and configuration changes alone, including enforcing unique passwords, disabling legacy protocols like HTTP and SNMP v1/v2, and quarterly backup restoration tests. The document references Order 117 and earlier FSTEC methodologies on vulnerability handling, serving as a practical self-assessment questionnaire rather than a mandatory regulation. Analysts note that many organizations still fail to implement low-cost measures such as excluding remote administration interfaces from DMZ zones and verifying backup recoverability.
Compliant Telegram Mini App Authentication via Russian ID Providers in My Anti-Social Network Project
The project 'My Anti-Social Network' demonstrates a production-grade approach to Telegram Mini App authorization that meets Russian identification requirements by separating user identity from delivery channels. Instead of relying solely on Telegram initData verification, the system routes authentication through VK ID, Yandex ID, and MAX using OAuth 2.0 / 2.1 flows with PKCE. Sensitive tokens never reach the browser; the client receives only short-lived one-time codes exchanged for HttpOnly session cookies. The architecture supports multiple front-ends including PWA, browser extensions, and Home Assistant integration while maintaining cryptographic protections around state parameters and code verifiers. The solution was implemented for an aggregator delivering personalized news feeds through Telegram, MAX, VK bots, and voice assistants.
Asset Management as the Foundation of Vulnerability Management: Unknown Assets Cannot Be Protected
The article explains that asset management forms the essential base for any effective vulnerability management program, as organizations cannot protect systems they do not know exist. It details multiple data sources including SIEM, NTA/NDR, Active Directory, CMDB, virtualization platforms, and cloud APIs that must be combined to build a complete inventory. Key record fields such as asset criticality, responsible owner, and last successful scan date are highlighted as critical for prioritization and SLA compliance. The piece examines new Russian regulations including FSTEC Order No. 117 and Federal Law No. 58-FZ that mandate accurate asset inventories to meet monthly scanning and 24-hour critical patch requirements. International frameworks such as CIS Controls v8.1, NIST CSF 2.0, and ISO/IEC 27001:2022 are compared, emphasizing lifecycle management and reaction processes for unauthorized assets. Emerging asset types including cloud resources, SaaS services, AI systems, containers, and IoT devices are discussed as expanding the attack surface faster than organizations can track.
Ozon Data Security Team Details Audit Framework to Eliminate Paper-Only Compliance
Alena, head of the Data Security group at Ozon, describes how the company built an internal audit process that focuses on actual risk reduction instead of producing lengthy formal reports. The team examines personal data, financial records, and other sensitive information across hundreds of microservices while checking role-based access, logging, encryption, and data flows. They analyzed more than 84,000 user-role pairs in one review and identified overly broad permissions on product tagging that could cause major financial losses. A notable case led to the removal of customer names, phones, and addresses from delivery boxes even though the practice was formally allowed under Federal Law 152-FZ. The group uses a scoring model based on data sensitivity, business importance, user count, and potential monetary impact to prioritize which systems to audit first. Additional criteria such as past incidents and critical information infrastructure status can be added to the model. The approach emphasizes real implementation of recommendations, cross-team communication, and hiring analysts who care deeply about practical security outcomes.