Sign in with Telegram vs WP Cassify

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.

If you’re happy with this plugin : As a reward for my efforts, I would like to receive T-shirts (or other goodies) as gifts from the universities or companies that use it. My size is L. Best regards. This Apereo CAS authentication plugin has no phpCas library dependency. This is not only an authentication plugin. You can build custom authorization rules according to cas user attributes populated. If user don’t exist in WordPress database, it can be created automatically. There are many features. You can customize everything. Website https://wpcassify.wordpress.com/ Development and release environment This plugin is now developed and tested from a github repository. You can find it here : https://github.com/WP-Cassify/wp-cassify-develop Don’t hesitate to contribute to this project. You can fork it and make pull requests ! Requirements Require at least PHP version 7.0 Require at least PHP CURL package Features included SLO (Single Log Out) support (thanks to dedotombo and me) Adding NCONTAINS operator (thanks to blandman) Fix bug on Gateway mode (autologin) (thanks to dedotombo again). Now it’s now necessary to hack theme files to fire it. Adding option logout on authentication failure to not disturb users Initialize PHP session at a later stage (on wp_loaded not on init) Adding some customs hooks and filters. Tested with Apereo CAS Server version 7.3.5 Compatible with CAS Protocol version 2 and 3 Automatic user creation if not exist in WordPress database. Synchronize WordPress User metas with CAS User attributes. Add support for multivaluate cas user fields. Now multivaluate fields can be serialized to be stored in custom WP User meta. Backup / Restore plugin configuration options settings You can choose CAS User attributes you want to populate. Then you can access them via PHP Session. Be careful, to access to CAS User Attributes from your theme file (from 1.8.4), use code below : wp_cassify_get_cas_user_datas() ); } ?> Set up WordPress Roles to User according to CAS User attributes. If plugin is network activated, you can define User Role Rule scope by blog id. Authorization rule editor. Compatible with WordPress Access Control Plugin. Manage URL White List to bypass CAS Authentication on certain pages. Much simpler bypass authentication with post method provided by Susan Boland (See online documentation). Create wordpress authentication form with redirect attribute like this (works only if URL bypass is enabled in settings) : true, 'remember' => true, 'redirect' => site_url( '/?wp_cassify_bypass=bypass' ), 'form_id' => 'loginform', 'id_username' => 'user_login', 'id_password' => 'user_pass', 'id_remember' => 'rememberme', 'id_submit' => 'wp-submit', 'label_username' => __( 'Username' ), 'label_password' => __( 'Password' ), 'label_remember' => __( 'Remember Me' ), 'label_log_in' => __( 'Log In' ), 'value_username' => '', 'value_remember' => false ); wp_login_form( $args ); ?> Receive email notifications when trigger is fired (after user account creation, after user login/logout). Define notifications rules based on user attributes values. Purge user roles before applying user role rules. Define user account expiration rules bases on CAS User attributes. Network activation allowed You can set Service Logout URL (Needs to have CAS Server with followServiceRedirects option configured). Add support for web application hosted behind a reverse proxy. (Thanks to franck86) Add custom hooks : wp_cassify_after_cas_authentication, wp_cassify_before_auth_user_wordpress, wp_cassify_before_redirect, wp_cassify_after_redirect. (See online documentation) Custom filter to perform custom cas server response parsing. Hook name : wp_cassify_custom_parsing_cas_xml_response (See online documentation) Custom shortcode to generate CAS login/logout link into your blog. (See online documentation) Debug settings, dump last xml cas server response. Detect if user has already authenticated by CAS from your public pages and perform auto-login with gateway mode Add ‘-IN’ and ‘-NOTIN’ operators to process array attributes values returned from CAS. When you have : $cas_user_datas['title'] = array( 'Student', 'Professor' ); Then you can use : (CAS{title} -IN "professor")