Drupal

Drupal connects to Veriqa through stock contrib modules. Only the site side changes: the Veriqa server and its distribution stay untouched.

Verified: Drupal 10 + openid_connect 3.0.0-alpha8 + openid_client_advanced 1.0.0-rc8; Telegram channel. Working: sign-in, user creation, id_token signature checked against JWKS, nonce, and PKCE S256.

1. Modules

composer require drush/drush "drupal/openid_connect:^3.0@alpha" "drupal/openid_client_advanced:^1.0@rc"
drush en openid_connect openid_client_advanced

openid_connect 3.0.0 is an alpha, which is worth factoring into your planning. openid_client_advanced pulls in firebase/php-jwt.

2. The client and the three switches

Configuration → People → OpenID Connect, the advanced plugin. Fill in issuer_url, the three endpoints (/connect/authorize, /connect/token, /connect/userinfo) and scopes.

PKCE is disabled in openid_connect itself at the code level (usesPkce() returns FALSE). PKCE S256, signature validation and nonce live in openid_client_advanced, and all three are off by default. “Drupal does PKCE” is only true once you have turned them on.

Turn on all three: use_pkce, use_nonce, and validate_signature with allowed_algorithms: [RS256]. The keys go in as JWKS JSON — the field expects the contents of the /.well-known/jwks document, not a link to it. Three more settings whose absence produces surprising behavior:

openid_connect.settings.user_login_display = above — otherwise the sign-in buttons are simply not visible on the form;
override_registration_settings and user.settings.register — they decide whether accounts may be created through the provider.

The redirect_uri is {site address}/openid-connect/{client entity id}. The most important part of this recipe. openid_connect rejects the sign-in when the provider returns no address: the log shows No email address provided by <provider>, and there is no setting to bypass it.

The check sits in context building, before the account is looked up — not in registration. So an already registered user without an email will not get in either: the email is required on every sign-in, not just the first one.

Telegram does not hand out addresses and never will. The way out is a hook the module documents itself (openid_connect.api.php) and invokes before that check, so the fix lives in your own module while the contrib module and Veriqa stay untouched:

mymodule.module

/**
 * Implements hook_openid_connect_userinfo_alter().
 */
function mymodule_openid_connect_userinfo_alter(array &$userinfo, array $context): void {
  if (!empty($userinfo['email'])) {
    return;
  }

  // With the default resolver `sub` already carries both parts as "{channel_type}:{channel_user_id}".
  $parts = explode(':', (string) ($userinfo['sub'] ?? ''), 2);
  if (count($parts) !== 2) {
    return;
  }

  [$channelType, $channelUserId] = $parts;
  $local = preg_replace('/[^a-z0-9]+/i', '-', $channelType . '-' . $channelUserId);
  $userinfo['email'] = strtolower($local) . '@' . strtolower($channelType) . '.veriqa.invalid';
}

The address comes out as telegram-123456789@telegram.veriqa.invalid. The .invalid domain is reserved by RFC 2606 and is guaranteed never to be delivered to — a deliberate trade-off rather than a free workaround: an account with such an address gets no password resets and no notifications. For a production site that is a decision you still have to make, not a complete solution: ask for the email in a second step, use progressive enrichment, or use the Email channel, where the address arrives in the claims.

`connect_existing_users` — the setting you cannot ignore

For a new user Drupal compares the address against existing accounts. With connect_existing_users enabled it will link the account it finds to the identity from Veriqa. With synthetic addresses that is safe: they are deterministic and unique per channel and id. But as soon as Veriqa starts returning a real address (the Email channel, or a resolver of your own), signing in through Veriqa takes over the local account with that address — the classic account takeover through an unverified email. Enabling this setting makes sense only when the IdP’s address verification is something you can rely on.

What you get

The account is created with the name from preferred_username (alice), and authmap gains a row provider=openid_connect.veriqa, authname=telegram:123456789 — Drupal links the identity by the Veriqa sub. The practical consequence: for Drupal, sub is the account key. If the way it is composed on the Veriqa side ever changes, previously created users stop being recognized.

Limitations

Verified with the Telegram channel; Drupal with Email, WhatsApp or the other channels has not been tested.
The hook above is an example, not a production-ready module: the decision about addresses belongs to the site.

Get started

Samples

Guides

Use cases

Ready-made recipes

Cloud

Reference

Releases

1. Modules

2. The client and the three switches

`connect_existing_users` — the setting you cannot ignore

What you get

Limitations

​1. Modules

​2. The client and the three switches

​3. Drupal requires an email — on every sign-in

​connect_existing_users — the setting you cannot ignore

​What you get

​Limitations

1. Modules

2. The client and the three switches

3. Drupal requires an email — on every sign-in

`connect_existing_users` — the setting you cannot ignore

What you get

Limitations