API Bearer Auth vs Sign in with Telegram

The API Bearer Auth plugin enables authentication for the REST API by using JWT access an refresh tokens. After the user logs in, the access and refresh tokens are returned and can be used for the next requests. Issued tokens can be revoked from within the users admin screen. See below for the endpoints. Note that after activating this plugin, all REST API endpoints will need to be authenticated, unless the endpoint is whitelisted in the api_bearer_auth_unauthenticated_urls filter (see FAQ for how to use this filter). JWT Access tokens can be formatted as JWT tokens. For this to work, you first have to create a secret and add it to the wp-config.php file. If you don’t do this, access tokens will work also, but are just random strings. To create a random secret key, you can do for example: base64_encode(openssl_random_pseudo_bytes(64)); And then add the result to wp-config: define('API_BEARER_JWT_SECRET', 'mysecretkey'); If you have problems, you can verify your JWT tokens at: https://jwt.io/ Revoke tokens This plugin adds a column to the users table in de admin where you can see when a token expires. You can also revoke tokens by selection the “Revoke API tokens” from the bulk actions select box. API endpoints Note that all endpoints expect JSON in the POST body. Login Endpoint: POST /api-bearer-auth/v1/login Request body: Note: client_name is optional. But if you use it, make sure to use it as well for the refresh call! {"username": "my_username", "password": "my_password", "client_name": "my_app"} Response: { "wp_user": { "data": { "ID": 1, "user_login": "your_user_login", // other default WordPress user fields } }, "access_token": "your_access_token", "expires_in": 86400, // number of seconds "refresh_token": "your_refresh_token" } Make sure to save the access and refresh token! Refresh access token Endpoint: POST /api-bearer-auth/v1/tokens/refresh Request body: Note: client_name is optional. But if you did use it for the login call, make sure to use it here as well! {"token": "your_refresh_token", "client_name": "my_app"} Response success: { "access_token": "your_new_access_token", "expires_in": 86400 } Response when sending a wrong refresh token is a 401: { "code": "api_api_bearer_auth_error_invalid_token", "message": "Invalid token.", "data": { "status": 401 } } Do a request After you have the access token, you can make requests to authenticated endpoints with an Authorization header like this: Authorization: Bearer Note that Apache sometimes strips out the Authorization header. If this is the case, make sure to add this to the .htaccess file: RewriteCond %{HTTP:Authorization} ^(.*) # Don't know why, but some need the line below instead of the RewriteRule line # SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0 RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1] If you are not logged in or you send an invalid access token, you get a 401 response: { "code": "api_bearer_auth_not_logged_in", "message": "You are not logged in.", "data": { "status": 401 } } Important update Update immediately if you’re using a version below 20200807. Before this version all access tokens were updated when calling the refresh callback. If you are affected by this the fastest solution is to execute this query: update wp_user_tokens set access_token_valid = NOW(); This will invalidate all access tokens. This means that all users need to refresh their access token and will get a new access token and a unique one this time. A big thank to @harchvertelol for reporting this and suggesting the fix as well!

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.