Authenticate Telegram users through protected Quorum sessions #14

Open
opened 2026-11-01 20:11:33 +00:00 by viacheslavshuka · 0 comments

Outcome

Users need one identity across the website and bot. Implement Telegram OIDC login with Authlib and PostgreSQL-backed Quorum browser sessions through asyncpg.

Keep provider handling in an adapter. The core defines identity, session, and completed-registration contracts. Registration progress grants no protected application access.

Acceptance criteria

  • Backend authorization and callback endpoints validate state, nonce, PKCE, and the expected ID token claims. Invalid or replayed responses create no authenticated session.
  • Identity uses stable verified provider identifiers. Mutable usernames do not identify accounts. Do not assume the OIDC subject equals the numeric Telegram recipient ID.
  • The browser receives an opaque Secure, HttpOnly, host-only cookie with an appropriate SameSite policy. Provider credentials never enter browser storage.
  • Login rotates the session. Logout revokes it on the server. Browser writes require CSRF protection independently of OIDC state validation.
  • Sessions expire after 30 days without user activity and at most 90 days after login. Background polling does not renew inactivity.
  • Protected operations require a completed registration with Telegram identity, a verified rating link, and required names. Registration progress cannot browse published tests or private data.
  • An ordinary login reuses the saved rating verification. Initial registration and recovery use their separate verification flows.
  • Every protected operation checks current restrictions. A blocked account receives its restriction notice without ordinary website or bot access.
  • Public landing, login, and recovery entry points remain accessible. No email/password account path or community invitation gate is added.
  • The same account can organize one test and participate in another. Permissions depend on the current operation and test, not a permanent organizer/tester account category.
  • Authentication responses use no-store. Generated OpenAPI describes security, success, rejection, and expiry behavior without exposing tokens or internal session records.

Validation design

Use controlled OIDC responses to detect missing state, nonce, issuer, audience, expiry, or replay validation. Exercise 30-day and 90-day boundaries with a controllable clock. Polling must leave the inactivity deadline unchanged. PostgreSQL tests must expose session reuse after logout or rotation. API tests must reject CSRF attempts and incomplete-registration credentials before returning protected data.

Dependencies

## Outcome Users need one identity across the website and bot. Implement Telegram OIDC login with Authlib and PostgreSQL-backed Quorum browser sessions through asyncpg. Keep provider handling in an adapter. The core defines identity, session, and completed-registration contracts. Registration progress grants no protected application access. ## Acceptance criteria - Backend authorization and callback endpoints validate state, nonce, PKCE, and the expected ID token claims. Invalid or replayed responses create no authenticated session. - Identity uses stable verified provider identifiers. Mutable usernames do not identify accounts. Do not assume the OIDC subject equals the numeric Telegram recipient ID. - The browser receives an opaque Secure, HttpOnly, host-only cookie with an appropriate SameSite policy. Provider credentials never enter browser storage. - Login rotates the session. Logout revokes it on the server. Browser writes require CSRF protection independently of OIDC state validation. - Sessions expire after 30 days without user activity and at most 90 days after login. Background polling does not renew inactivity. - Protected operations require a completed registration with Telegram identity, a verified rating link, and required names. Registration progress cannot browse published tests or private data. - An ordinary login reuses the saved rating verification. Initial registration and recovery use their separate verification flows. - Every protected operation checks current restrictions. A blocked account receives its restriction notice without ordinary website or bot access. - Public landing, login, and recovery entry points remain accessible. No email/password account path or community invitation gate is added. - The same account can organize one test and participate in another. Permissions depend on the current operation and test, not a permanent organizer/tester account category. - Authentication responses use no-store. Generated OpenAPI describes security, success, rejection, and expiry behavior without exposing tokens or internal session records. ## Validation design Use controlled OIDC responses to detect missing state, nonce, issuer, audience, expiry, or replay validation. Exercise 30-day and 90-day boundaries with a controllable clock. Polling must leave the inactivity deadline unchanged. PostgreSQL tests must expose session reuse after logout or rotation. API tests must reject CSRF attempts and incomplete-registration credentials before returning protected data. ## Dependencies - [#6: Start the FastAPI runtime with owned database resources](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/6). Provides HTTP endpoints and resource ownership. - [#8: Apply PostgreSQL migrations with release compatibility checks](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/8). Provides durable account and session storage. - [#7: Create the React application with locked frontend tooling](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/7). Provides the browser application for public login and protected navigation. ## Related work - [#27: Complete registration through verified rating-profile control](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/27) - [#19: Let users inspect and revoke browser sessions](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/19) - [#49: Restore account access through moderator-approved Telegram relinking](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/49) - [#69: Restrict participation and organizing capabilities with reversible expiry](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/69) - [#10: Generate and verify OpenAPI and the TypeScript client](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/10)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
viacheslavshuka/quorum#14
No description provided.