Skip to main content
TYPO3 connects through the causal/oidc extension. Nothing changes on the Veriqa side.
Verified: TYPO3 13.4.34 + causal/oidc 5.0.0; Telegram channel. Working: sign-in, fe_user creation and a session, identity linked by the Veriqa sub.

​
1. Installation

The extension needs TYPO3 12.4.33+/13.4.14+ and PHP 8.2+, and pulls in league/oauth2-client and firebase/php-jwt.

​
2. Configuration

The settings live in config/system/settings.php under EXTENSIONS.oidc, not in the database: The redirect_uri is free-form in TYPO3 — unlike Drupal and Joomla, where the module dictates it. A middleware intercepts any frontend GET carrying code/state/error in the query, so you can register, for example, the site root.
Give the sign-in its own page. The oidc_login plugin redirects to the IdP as the page renders — putting it on the front page sends every visitor to sign in.

​
3. The default group — without it the sign-in does not work

This is TYPO3’s main trap, and it is dangerous twice over. The extension does not create a new user who ends up in no group. Groups come either from a Roles claim — Veriqa does not issue one — or from usersDefaultGroup. So you have to create an fe_groups record by hand and point the setting at its uid. The other half of the trap is diagnostics. The refusal is logged at INFO, while TYPO3’s default logger has its threshold at ERROR. From the outside it looks like this:
  • the page shows a bare “Login failed! Please try again.”;
  • the TYPO3 log says nothing about the reason;
  • the Veriqa logs are all green: token 200, userinfo 200.
The failure happens after a successful exchange, so the integrator looks for the problem at the IdP while it sits on their own side. Turn on a diagnostic logger before the first sign-in, not after.

​
4. What the extension verifies — and what it does not

The extension does not verify the id_token signature — it has no JWKS setting at all: the identity comes from the /connect/userinfo response, with trust resting on TLS. That is a legitimate choice (OIDC Core §3.1.3.7), but Veriqa’s signature goes unchecked on the TYPO3 side.
The extension does not send nonce and does not check iss — its only replay protection is state plus its own context cookie. For a strict RP that is weaker than Drupal’s. oidcEndpointUserInfo is mandatory. The fallback path that reads the identity out of the id_token carries an extension defect that raises a fatal error on PHP 8 instead of signing the user in. Leaving the field empty is not an option.

​
Email and the username

TYPO3, like WordPress, does not require an email: the default plugin.tx_oidc.mapping.fe_users mapping does not map it at all. A sign-in through a messaging app creates a working fe_user without the synthetic .invalid addresses that Drupal and Bitrix need. The price is the usual one: by default username is <sub>, that is telegram:123456789. A human-readable name comes from overriding the mapping to <preferred_username>. The identity is linked by the Veriqa sub — if the way it is composed on the Veriqa side ever changes, previously created users stop being recognized.

​
Limitations

Verified with the Telegram channel; TYPO3 with Email, WhatsApp or the other channels has not been tested.