Known limitations

These limitations are described on their own pages as well — here they are gathered in one place so that the “does this fit” decision happens before an integration rather than halfway through it.

Not in the product

Limitation	Details
The cloud has not opened yet	Veriqa Cloud is coming soon; its documentation already describes the fixed API contract — Veriqa Cloud. Until then, use self-hosted
No provider-side sign-out	There is no `end_session_endpoint` — see OIDC support
Email Push is off by default	Signing in by sending a pre-filled email (the one-tap email) is enabled with `Channels:Email:PushEnabled` and requires inbound configuration — Channels

Operations

Limitation	What to account for
Key replacement is not seamless	The configuration accepts one signing and one encryption certificate, so old and new keys never overlap: replacing one invalidates live tokens. Plan it as an operation that invalidates sessions — Preparing for production
More than one instance needs shared state	A SignalR backplane and shared DataProtection keys, otherwise instances cannot read each other’s cookies and tokens — self-hosted, running more than one instance
Rate limiting is per instance	There are no cluster-wide limits — put a limiter in front of the application if you need them
No per-IP limits in the core	Buckets are counted per route, per user or per client, never per address, and the core does not block addresses. A per-IP limiter and address blocking live on the reverse proxy / WAF — Preparing for production

Channel properties your application will see

Limitation	What to account for
Telegram carries no email	And it will not. If your application requires an address, Veriqa collects it inside the sign-in (a required `email`), or your own code supplies it — Getting the phone number and email
`picture` needs the `avatar` scope and comes through userinfo	The avatar is the image itself, a `data:` URI (from MAX possibly an `https` URL). It is issued only to a client that requests `avatar`, only through `/connect/userinfo`, and never in the `id_token` — Resolved identity and claims
On the Email channel `name` equals the address	There is no display name to take, so the shape of the account depends on the channel
`family_name` does not always arrive	Only when the channel supplied a last name: it is optional in Telegram and MAX, and absent on Email

Verified compatibility

Area	Status
WordPress, Drupal, TYPO3, Joomla, Bitrix	✅ verified — CMS integrations
GitLab, Keycloak, Grafana, Nextcloud, Odoo, Moodle	✅ verified — business systems
Discourse	🟡 signing in an existing user is verified; account creation is not
Shopify, Wix	⚠️ connecting to the platform itself is not verified; what it takes — SaaS builders
Mattermost	⚠️ not verified
A public deployment (real domain + valid certificate)	⚠️ not verified
The WhatsApp and MAX channels with client applications	⚠️ not verified; Telegram and Email are
The Viber channel on the live platform	⚠️ not verified: the adapter has been run only against a mock of the Bot API. Since 5 February 2024 Viber issues new bots on commercial terms only, so the bot and its token are obtained from Viber before a deployment — Viber
Roles, groups and permissions from claims	⚠️ not verified in any system

Deviations from the specifications

Two known differences between Veriqa’s behavior and what a client may expect — an opaque reference access token instead of a JWT and a strict refusal of scope in the token request — are described in OIDC and OAuth 2.0 support. That page also states that there is no formal OpenID Foundation certification. Resource indicators (RFC 8707) are not supported. Veriqa registers no resources, so a resource parameter is rejected with invalid_target for any value. This behavior is not configurable. Clients written for Microsoft Entra ID often send the parameter anyway (see Moodle); for such a client the per-client quirk drop-resource-parameter strips it before validation, which is a relaxation of the request form and not support for resource indicators — no audience is granted.

Get started

Samples

Guides

Use cases

Ready-made recipes

Cloud

Reference

Releases

Known limitations

Not in the product

Operations

Channel properties your application will see

Verified compatibility

Deviations from the specifications

​Not in the product

​Operations

​Channel properties your application will see

​Verified compatibility

​Deviations from the specifications

Not in the product

Operations

Channel properties your application will see

Verified compatibility

Deviations from the specifications