Datawiza

The Proxy Auth Plugin helps developers/DevOps/admins easily implement authentication and authorization for WordPress by using a <a href="https://en.wikipedia.org/wiki/JSON_Web_Token" rel="nofollow ugc">JWT (JSON Web Token)</a> provided by a reverse proxy.
This could be employed to achieve SSO (OAUTH/OIDC and SAML) to a Cloud Identity Provider (e.g., Azure Active Directory, Okta, Auth0) by using an Identity-Aware Proxy, e.g., <a href="https://www.datawiza.com/" rel="nofollow ugc">Datawiza Access Broker</a> and <a href="https://cloud.google.com/iap" rel="nofollow ugc">Google IAP</a>.
Note that the plugin requires a reverse proxy sitting in front of the WordPress site. The reverse proxy performs authentication, and passes the user name and role in a JWT to the plugin via a HTTP header called <code>DW-TOKEN</code>.
By using <a href="https://www.datawiza.com/" rel="nofollow ugc">Datawiza Access Broker</a>, you get a <a href="https://docs.datawiza.com/step-by-step/step1.html" rel="nofollow ugc">configuration-based</a> <a href="https://docs.datawiza.com/" rel="nofollow ugc">no-code solution</a>, following the detail instruction <a href="https://docs.datawiza.com/step-by-step/step1.html" rel="nofollow ugc">here</a>.
If you decide to use your own reverse proxy, please follow the instructions below.
How it works
<ul>
<li>The plugin retrieves the user id (email) from the JWT and then checks if such a user exists. If not, the plugin creates a new user by using this email and signs him/her in.</li>
<li>The plugin retrieves the user role from the JWT and sets it as the user’s role in WordPress.</li>
<li>
The plugin expects the JWT including user id and role as a HTTP header <code>DW-TOKEN</code>. For example, the payload of JWT may look like:
{ 
 “role”: “administrator”, 
 “email”: “admin@yourwebsite.com” 
}
</li>
</ul>
Plugin config in WordPress
In <code>Setting</code> -> <code>Datawiza Proxy Auth</code>, you need to input a private secret which is used as a Cryptography Key. Such secret is shared between the plugin and the reverse proxy which is responsible for passing the JWT to the plugin. The Signing Algorithm for the JWT is <code>HS256</code>.
!!! NOTES !!!
<ul>
<li>If the enabled Proxy Auth Plugin cannot retrieve the expected JWT in the HTTP header, the plugin will not work. The authentication will use the default authentication of wordpress and you will see an error banner on top of the wordpress pages.</li>
<li>MAKE SURE that clients cannot bypass the reverse proxy. This is to prevent people from sending forged malicious requests with arbitrary JWTs directly to WordPress.</li>
<li>It’s recommended that the reverse proxy in front of the WordPress site erases the incoming http request’s <code>DW-TOKEN</code> header. The <code>DW-TOKEN</code> header should be generated by the reverse proxy only.</li>
<li>If admin doesn’t assign role to the user, user’s role will be subscriber for WordPress by default.</li>
<li>If user’s role has been updated in JWT, the plugin will update the role in WordPress accordingly.</li>
</ul>
Generate the JWT required by the plugin
If you are using openresty/lua-nginx-module, here is the code sample to generate the JWT required by the plugin:
<pre><code>jwt = require("resty.jwt")
local jwt_token = jwt:sign(
 "jwt_secret",
 {
 header={typ="JWT", alg="HS256"},
 payload={email="admin@yourwebsite.com", role="administrator"}
 })
ngx.req.set_header('DW-TOKEN', jwt_token)
</code></pre>
The <code>jwt_secret</code> above should be the same private secret input in <code>Setting</code> -> <code>Datawiza Proxy Auth</code>. The <code>role</code> in <code>payload</code> is optional. If it’s not specified, the default role is <code>subscriber</code>. For more details about <code>lua-resty-jwt</code>, you can visit <a href="https://github.com/SkyLothar/lua-resty-jwt" rel="nofollow ugc">here</a>.

Datawiza Proxy Auth Plugin – SSO

The Proxy Auth Plugin helps developers/DevOps/admins easily implement authentication and authorization for WordPress by using a JWT (JSON Web Token) p …

Automattic

Manzoor Wani

Gergely J

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 <a href="https://core.telegram.org/bots/telegram-login" rel="nofollow ugc">Telegram’s standard OpenID Connect login</a>: a secure redirect to Telegram and back. It works reliably in every browser, including ones with strict tracker blocking turned on.
<h4>Features</h4>
<ul>
<li>“Sign in with Telegram” button on the standard <code>wp-login.php</code> screen, as a <code>[telegram_signin_button]</code> shortcode anywhere on your site, or as a Block Editor block.</li>
<li>Account linking from the user profile screen — existing WordPress users can connect or disconnect their Telegram account.</li>
<li>Profile sync — display name and avatar from the user’s Telegram profile flow through to the WordPress profile automatically.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
<h4>How it compares to the legacy Login Widget</h4>
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:
<ul>
<li>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.</li>
<li>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.</li>
<li>Key rotation is manual — changing the HMAC key means rotating the bot token in BotFather and updating it on every server that verifies logins.</li>
</ul>
Sign in with Telegram uses Telegram’s newer OpenID Connect provider instead — a standard server-side redirect flow with a properly signed RS256 <code>id_token</code>. 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.
<h3>External services</h3>
This plugin connects to Telegram’s OpenID Connect provider at <code>oauth.telegram.org</code> 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:
<ul>
<li>Sign-in start. When a visitor clicks the “Sign in with Telegram” button, their browser is redirected to <code>oauth.telegram.org</code> with the bot’s Client ID, the requested scopes (always <code>openid</code> and <code>profile</code>; additionally <code>phone</code> and / or <code>telegram:bot_access</code> if you enabled those in Settings → Sign in with Telegram), a random <code>state</code>, a random <code>nonce</code>, and a PKCE <code>code_challenge</code> (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.</li>
<li>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>code</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>code</code>, the matching PKCE <code>code_verifier</code>, and the redirect URI. Telegram responds with a signed <code>id_token</code> containing the visitor’s Telegram identifier, name, profile picture URL, and (if the <code>phone</code> scope was granted) phone number.</li>
<li>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 <code>oauth.telegram.org</code>. Both responses are cached in WordPress transients. If a later <code>id_token</code> 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.</li>
</ul>
This service is provided by Telegram. Refer to Telegram’s <a href="https://telegram.org/tos" rel="nofollow ugc">Terms of Service</a> and <a href="https://telegram.org/privacy" rel="nofollow ugc">Privacy Policy</a> for details on how Telegram handles the sign-in.

Sign in with Telegram

Add Telegram login to your WordPress site. Visitors sign in with their existing Telegram account — no new password to remember.

Datawiza Proxy Auth Plugin – SSO vs Sign in with Telegram