Skip to main content
Users sign in to WordPress through Veriqa with the stock plugin — neither the Veriqa core nor its distribution changes for a CMS. Everything needed lives on the site side: the plugin, its settings, and one adjustment to the request shape described below.
Verified: WordPress 6 + openid-connect-generic 3.11.3; Telegram channel. Working: sign-in, automatic user creation, id_token signature checked against JWKS. WordPress with Email, WhatsApp or the other channels has not been tested.

​
What you need

  • a running Veriqa server reachable from the site (in production: a public HTTPS address with a valid certificate);
  • a client registered in Veriqa: client_id, client_secret, and a redirect_uri of the form https://your-site/wp-admin/admin-ajax.php?action=openid-connect-authorize;
  • administrator access in WordPress.
The client must be confidential — one with a secret. Veriqa lets such a client sign in without PKCE, and that is what makes off-the-shelf CMS plugins workable.

​
1. The plugin

Install openid-connect-generic (10k+ installs, actively maintained). The alternatives do not fit: nicko170/wp-openid has not shipped since 2023, the Scouting plugin is pinned to someone else’s issuer, and miniOrange keeps the settings you need behind its paid edition.

​
2. Plugin settings

Take the addresses from your server’s discovery document (https://veriqa.example.com/.well-known/openid-configuration): Four settings deserve to be named explicitly — they decide what the account looks like:
  • Leave identity_key alone. With the default, the username is human-readable (alice); setting it to sub by hand produces a username like telegram123456789.
  • nickname_key → preferred_username, displayname_format → name.
  • Turn enable_logging on, at least while you set things up: the plugin log shows why a sign-in fails.
  • Leave no_sslverify off. TLS verification should work; if it gets in the way, the problem is the certificate, not the check.

​
3. Drop scope from the code exchange

This step is mandatory, and it is worth understanding rather than just applying. The plugin puts scope into the grant_type=authorization_code request, where RFC 6749 §4.1.3 does not provide for it: the granted scope comes from the authorization code itself. Keycloak, Auth0 and Azure silently ignore the extra parameter — a strict OpenIddict server rejects the request (OpenIddict issue #1729 is closed as invalid).
Removing the parameter makes the request conform to the standard. It is not a way around a check and not a weakening of your security: what gets removed is something that should not be in the request at all.
There are two options and they are interchangeable — you do not need both. Which one fits depends on whose side you can change: the site, or the Veriqa deployment.

The site owner fixes it

A six-line mu-plugin on the WordPress side. The Veriqa server is untouched — the right choice when Veriqa is not yours (the cloud, or someone else’s deployment).

The Veriqa owner fixes it

The drop-scope-on-code-exchange compatibility quirk — a relaxation scoped to a single ClientId on the server side. The right choice when there are many sites and touching each one is not practical.

​
Option A — the mu-plugin

Drop the file into wp-content/mu-plugins/ (create the directory if it is missing). Must-use plugins load automatically — there is nothing to activate in the admin area.
wp-content/mu-plugins/veriqa-oidc-compat.php
The change is surgical: scope is dropped only for the get-authentication-token operation. It stays on token refresh, where RFC 6749 §6 does allow narrowing the scope.

​
Option B — the quirk on the Veriqa side

The same parameter, removed by the server, for one client. Enabling it takes two steps, and Veriqa logs a warning about every enabled quirk at startup:
appsettings.json
The details, the removal condition and the wordpress-openid-connect-generic profile are in Client compatibility. With neither option in place the sign-in fails at the code exchange, and WordPress sends the browser back to wp-login.php?login-error=invalid_request&message=….

​
What you get

The plugin log shows login-success Successful login for: telegram123456789; the click-to- signed-in time is around twenty seconds, including everything the person does on their phone. The user is created automatically. The account is created with an empty email — Telegram does not hand out addresses and never will. If your site requires one, there are two paths: use the Email channel (the address then arrives in the claims), or have WordPress ask for it after the first sign-in.

​
Limitations

  • Verified with the Telegram channel. On the Email channel the profile looks different: name repeats the address instead of carrying a human-readable name, so a recipe tuned on Telegram produces a different-looking account.
  • A dedicated “Veriqa for WordPress” plugin is not needed: the stock plugin covers the job end to end.
  • The avatar is not part of this recipe: picture is a data: image URI issued only for the avatar scope and only through userinfo, and the plugin setup above does not request that scope.