Troubleshooting - Veriqa

Look up a symptom by its error text — most of them mean something other than what they appear to say.

Failures at `/connect/authorize` and `/connect/token`

Symptom	Cause and what to do
`invalid_request` · `ID2029` — `The mandatory 'code_challenge' parameter is missing`	PKCE is mandatory for this client because it is registered as public. Either add PKCE or make the client confidential — off-the-shelf CMS plugins usually need the latter.
`invalid_request` · `ID2054`	The same thing, in newer wording.
`invalid_request` · `ID2032` — `The specified 'code_challenge_method' is not supported`	`code_challenge_method=plain` was sent. Only `S256` is supported. The same `ID2032` covers several “not supported” refusals — go by `error` and `error_description`, not by the number.
`unsupported_response_type` · `ID2032` — `The specified 'response_type' is not supported`	The client is asking for the implicit flow (`response_type=token` or `id_token`). Veriqa accepts `code` only: implicit was removed in OAuth 2.1 as unsafe. The classic case is Odoo’s stock `auth_oauth` module; what to install instead is on the Veriqa in business systems page.
`invalid_target` · `ID2190` — `One of the specified 'resource' parameters is invalid`	The client sends a `resource` parameter (RFC 8707 resource indicators). Veriqa registers none, so any value is rejected. Moodle’s `auth_oidc` plugin, written for Microsoft Entra ID, behaves this way — see Veriqa in business systems. For a client that cannot be told to stop, enable the per-client quirk `drop-resource-parameter`.
`invalid_request` · `ID2087` — `Multiple client credentials cannot be specified`	The client sends its credentials both in an `Authorization: Basic` header and in the body, while RFC 6749 §2.3.1 allows one method. A Joomla classic: clear the “In Header” checkbox.
The token endpoint rejects a CMS plugin’s request	An extra `scope` in the `grant_type=authorization_code` request. The explanation and two ways to fix it are on the WordPress page.
`invalid_grant` · `ID2001`	The authorization code is corrupted or expired.
`400` · `ID2083` — `This server only accepts HTTPS requests`	The issuer is served over `http`. Note that a `redirect_uri` over `http` is still accepted — this symptom is about the issuer address specifically.
`access_denied` at the `redirect_uri`	The user declined the confirmation or pressed Cancel sign-in, or Veriqa refused the sign-in by a rule of its own: a claim the client requires could not be obtained from the user, or the user exceeded the limit of sign-in requests. Not an integration error; an immediate retry of the same request gets the same response. An ASP.NET Core client on `AddOpenIdConnect` responds to it with an HTTP 500 unless `AccessDeniedPath` is set — see step 5 of the .NET quickstart. The callback of the Node.js and Python quickstarts catches the library’s error for it; Spring `oauth2Login()` sends the user to `/login?error` by itself.
`server_error` at the `redirect_uri`	The sign-in started and then failed on the Veriqa side: the channel could not carry the confirmation out, the user’s identity could not be resolved, or the sign-in could not be finalized. The response carries `error`, `state` and `iss` and no `error_description`; the reason is in the Veriqa log and in the audit trail, under the transaction. Handle it as a failed sign-in and offer to start again. An ASP.NET Core client on `AddOpenIdConnect` raises `OnRemoteFailure` for it and answers with an HTTP 500 unless that event is handled — `AccessDeniedPath` covers `access_denied` only; see step 5 of the .NET quickstart.

Failures during confirmation

Symptom	Cause and what to do
`503 channel_display_failed`	No channel is enabled.
`400 no_channel_for_required_phone` at `/connect/authorize`	The phone number is required, and none of the channels available to the request can provide it — `acr_values` may have narrowed them. The requirement comes from `RequirePhone` or `Level: Required` on `phone_number` in `Veriqa:ScopesClaims`, from `RequirePhone` or `ClaimLevels` of the client entry, or from `essential: true` on `phone_number` in the request’s `claims` parameter. If no registered channel can meet a configured requirement, a warning about it was already logged at startup. Enable a channel that provides the phone number, or lift the requirement.
`400` · `browser_nonce_mismatch` — `Browser nonce does not match` at `/connect/authorize/callback`	A different transaction was confirmed: the authorize page was reloaded, and the one-time browser cookie belongs to the latest load. This is the built-in protection against confirming someone else’s session. Retry the sign-in without reloading the page.
`500` · `email_delivery_failed` at `/auth/email/start`, on every other attempt	A known limitation: on an SMTP server without authentication the sender reconnects over an already open connection, so every second attempt fails. A repeat request goes through.
`429` at `/auth/email/start`	The Email channel’s rate limit after several requests in a row. Pause between requests when debugging.

Symptoms on the application side

Symptom	Cause and what to do
A silent `Login failed! Please try again.` in TYPO3 while the Veriqa logs are green	The user has no group: `usersDefaultGroup` is unset. The reason is logged at INFO and invisible under TYPO3’s default logger — see TYPO3.
`No email address provided by <provider>` in Drupal	The channel returned no email, and Drupal requires one on every sign-in. The fix is on the Drupal page.
WordPress returns to `wp-login.php?login-error=invalid_request`	The same extra `scope` in the code exchange — see WordPress.
In Bitrix every sign-in signs the user in as the administrator	A `CUser::GetList` filter written in D7 syntax is silently dropped and the first user is picked. The details are on the Bitrix page.
In Moodle, “Error in OpenID Connect. Please check logs for more information.”	Moodle never reached Veriqa: its outbound-request protection fired — by address (`curlsecurityblockedhosts`) or by port (`curlsecurityallowedport`, only 443 and 80 by default). The real cause (`The URL is blocked.`) shows up only after the plugin’s `debugmode` is switched on. The port restriction applies on a public address too — see Veriqa in business systems.
In Moodle, “The given username contains invalid characters”	Moodle builds the username from the Veriqa `sub`, which looks like `telegram:1234` — a colon is not allowed in usernames. Request the `profile` scope, so the name comes from `preferred_username`, or enable `extendedusernamechars`.
In Odoo the provider button is there, but sign-in fails with a generic access-denied error	The OIDC module is missing the `python-jose` library: its import is wrapped in a silent branch that only writes to the debug log. The module installs and looks healthy regardless.
In Odoo a bare error page opens instead of returning to the site	The stock `auth_oauth` module is configured, and it only speaks the implicit flow. See the `unsupported_response_type` row above.

Log entries at startup

Symptom	Cause and what to do
On the first start against an empty PostgreSQL database, an `Error` in the category `Microsoft.EntityFrameworkCore.Database.Command`: `Failed executing DbCommand … SELECT "MigrationId", "ProductVersion" FROM "__EFMigrationsHistory"`, and in the PostgreSQL log `relation "__EFMigrationsHistory" does not exist`. When the audit trail is kept in a database too — on the standalone server it shares the transaction database by default — a second such entry follows for its own history table, `__AuditTrailMigrationsHistory`. With the collected claims store turned on, one more follows for `__CollectedClaimsMigrationsHistory` — also on the first start after turning the store on against a database already in use	Normal behavior, nothing to fix. Before applying migrations EF Core reads its migration history table; on an empty database that table does not exist yet, and EF Core logs the refusal at `Error` level. It then creates the table and applies the migrations — the start continues and the health checks turn green. On the next starts against the same database these entries are gone. If one repeats on every start, or the start does not finish, that is a real failure: check the connection string and the database user’s rights.

The plugin’s own log on the application side is often more useful than Veriqa’s: a failure that happens after a successful code exchange looks like a normal sign-in in the Veriqa logs. If Veriqa is all green and the user is still not signed in, the cause is almost certainly on the CMS side.