Authorizer vs Sign in with Telegram

Authorizer restricts access to a WordPress site to specific users, typically students enrolled in a university course. It maintains a list of approved users that you can edit to determine who has access. It also replaces the default WordPress login/authorization system with one relying on an external server, such as Google, CAS, LDAP, or an OAuth2 provider. Finally, Authorizer lets you limit invalid login attempts to prevent bots from compromising your users’ accounts. View or contribute to the plugin source on GitHub: https://github.com/uhm-coe/authorizer Authorizer requires the following: CAS server (2.x, 3.x, 4.x, 5.x, 6.x, or 7.x) or LDAP server (plugin needs the URL) PHP extensions: php-ldap, php-curl, php-dom Authorizer provides the following options: Authentication: WordPress accounts; Google accounts; CAS accounts; LDAP accounts; OAuth2 accounts Login Access: All authenticated users (all local and all external can log in); Only specific users (all local and approved external users can log in) View Access: Everyone (open access); Only logged in users Limit Login Attempts: Progressively increase the amount of time required between invalid login attempts. Shortcode: Use the [authorizer_login_form] shortcode to embed a wp_login_form() outside of wp-login.php.

Sign in with Telegram lets your visitors log in with their Telegram account — no extra password to remember, no new account to create. Unlike older Telegram-login plugins that rely on a script embedded from Telegram (which modern privacy-focused browsers often block), this plugin uses Telegram’s standard OpenID Connect login: a secure redirect to Telegram and back. It works reliably in every browser, including ones with strict tracker blocking turned on. Features “Sign in with Telegram” button on the standard wp-login.php screen, as a [telegram_signin_button] shortcode anywhere on your site, or as a Block Editor block. Account linking from the user profile screen — existing WordPress users can connect or disconnect their Telegram account. Profile sync — display name and avatar from the user’s Telegram profile flow through to the WordPress profile automatically. No automatic account merging — a Telegram identity can only attach to an existing WordPress user through an explicit click-to-link action from a logged-in session, so a stranger who happens to share an email address can never take over an account. Secure by default — uses the same kind of modern, signed redirect flow that “Sign in with Google” and “Sign in with Apple” use. No shared bot-token secret on your server, no manual key rotation. Settings page in wp-admin where you paste the bot’s Client ID + Client Secret, pick the default role for new users, and optionally collect the visitor’s verified phone number or request permission for your bot to message them directly. How it compares to the legacy Login Widget Telegram’s older Login Widget (used by most existing Telegram-login plugins on the directory) is not OAuth or OpenID Connect. It loads a JavaScript file from telegram.org that renders Telegram’s button on your page and then hands the auth result either to a JavaScript callback or to a server URL. Either mode still needs the embedded script to render the button in the first place. That setup is increasingly fragile: Browsers with strict third-party-script blocking — Brave with default shields, Firefox Enhanced Tracking Protection on Strict, Safari Lockdown Mode, uBlock Origin filter lists — frequently block the embedded script outright, so the button never renders and visitors have no way to start the flow. The widget’s authentication hash is an HMAC-SHA256 over your bot token, so anyone who wants to verify a login has to hold a copy of that secret. There’s no standard JWT / JWKS story to lean on. Key rotation is manual — changing the HMAC key means rotating the bot token in BotFather and updating it on every server that verifies logins. Sign in with Telegram uses Telegram’s newer OpenID Connect provider instead — a standard server-side redirect flow with a properly signed RS256 id_token. No third-party scripts on your pages, no shared bot-token secret with verifiers, automatic key rotation via JWKS. It behaves the same regardless of how privacy-locked-down the visitor’s browser is. External services This plugin connects to Telegram’s OpenID Connect provider at oauth.telegram.org so visitors can sign in with their Telegram account. No data is sent to Telegram unless a visitor actively starts a sign-in. What is sent, and when: Sign-in start. When a visitor clicks the “Sign in with Telegram” button, their browser is redirected to oauth.telegram.org with the bot’s Client ID, the requested scopes (always openid and profile; additionally phone and / or telegram:bot_access if you enabled those in Settings → Sign in with Telegram), a random state, a random nonce, and a PKCE code_challenge (SHA-256). The only user-specific traffic at this step is the browser redirect itself. If the discovery cache is cold (see below), building the redirect URL also triggers an anonymous server-side GET of the discovery document — no user data in that request. Sign-in callback. After the visitor approves the sign-in on Telegram’s side, Telegram redirects them back to your site with an authorization code. The plugin then makes a single server-to-server POST to Telegram’s token endpoint, sending the Client ID + Client Secret (as HTTP Basic auth), the code, the matching PKCE code_verifier, and the redirect URI. Telegram responds with a signed id_token containing the visitor’s Telegram identifier, name, profile picture URL, and (if the phone scope was granted) phone number. Discovery + JWKS lookup. The first sign-in after activation (and again after the local cache expires, 12 hours) triggers a one-off, anonymous GET to Telegram’s OpenID Connect discovery document and JSON Web Key Set (JWKS) at oauth.telegram.org. Both responses are cached in WordPress transients. If a later id_token references a signing key that isn’t in the cache (Telegram rotated keys), the JWKS is re-fetched once; a short cooldown prevents repeated refresh attempts. No user data is sent in any of these requests. This service is provided by Telegram. Refer to Telegram’s Terms of Service and Privacy Policy for details on how Telegram handles the sign-in.