Skip to main content
Users sign in to Joomla through Veriqa with the miniOrange OAuth Client plugin. The technical side is clean — no code changes at all. The limitation here is different: the free version does not create users.
Verified: Joomla 5 + miniOrange OAuth Client 3.2.0 (free); Telegram channel. Working: sign-in to an existing account. The free build has no user auto-creation.
The main limitation is commercial. To an unknown user the free version shows “User Auto-Creation Not Available in Current Plugin Version” with an upgrade link. The build contains no account-creation code at all — only a lookup of an existing account by email = X OR username = Y.So what you get for free is a different scenario than on WordPress and Drupal: there the messaging app covers registration from scratch, here it only signs people in to accounts an administrator created.

​
Installation and setup

Install miniOrange OAuth Client 3.2.0 (GPLv2, J3–J6). The zip downloads from a direct link and no miniOrange account is needed. The open alternative damyvv/openidconnect-joomla is dead — last commit in 2023, it never saw Joomla 5.
  1. Install the package.
  2. Enable the PLG_SYSTEM_MINIORANGEOAUTH plugin — it arrives disabled.
  3. Configuration → the Custom OpenID Connect App provider → client_id, client_secret, the three endpoints, scopes.
  4. Clear the “In Header” checkbox in the “Set Client Credentials” block.
On Joomla 4+ the redirect_uri is a web-service route rather than a site page: {site}/api/index.php/v1/miniorangeoauth. The sign-in link is the same path with ?morequest=oauthredirect&app_name=openidconnect.

​
Three installation pitfalls

  1. The installer is misleading. You get Can't find XML setup file (a warning) right next to Installation successful. The installation is fine — the warning is about an intermediate archive inside the package.
  2. The system plugin is disabled after installation. Without it the sign-in does not work, and the interface does not make this obvious.
  3. ID2087 at the code exchange. By default the plugin sends the credentials both in an Authorization: Basic header and in the request body, while RFC 6749 §2.3.1 allows only one method. Clearing “In Header” fixes it. The plugin’s own message (“check your client id and secret”) points the wrong way — they are not the problem.

​
Email: the requirement exists, and the free version offers no way around it

The plugin resolves the email before looking up the account, that is, on every sign-in, and aborts in two cases: the email_attr mapping is unset (“Login not Allowed. Attribute Mapping is empty”), or it is set but the attribute arrived empty ([MOOAUTH-008] : Email attribute is not received.). The value’s format is never checked — the requirement is about a non-empty value, not about an email address.
email_attr corrupts the account. On every sign-in the plugin overwrites the account’s email with the mapped value, without validating the format. If you map it to sub, joom_users ends up holding telegram:123456789 instead of alice@veriqa.invalid, after which password resets and notifications stop working.There is no correct value for Telegram: it hands out no address. The supported way around this is the paid version with attribute mapping.

​
What the free version covers

Configuration and Logger are available. User auto-creation, attribute and role mapping, and advanced login are not. Verified with the Telegram channel; Joomla with Email, WhatsApp or the other channels has not been tested.