Disclaimer: This troubleshooting guide is based on real cases reported on the PKP Community Forum and verified against the PKP issue tracker. The steps address the most commonly encountered causes of ORCID authentication failure after an OJS 3.3-to-3.5 upgrade. Individual installations may have different underlying issues — always check your server logs for the specific error before applying fixes.
Table of Contents
Why ORCID Authentication Matters
ORCID is more than an identifier — it is the backbone of author disambiguation in scholarly publishing. When ORCID authentication works correctly in OJS, several critical workflows become seamless:
- Authors can link their ORCID iD during submission without manually entering publication history. The system pulls verified data directly from the ORCID registry, reducing data entry errors.
- Reviewers are recognized through their ORCID iD, giving journals a reliable way to track reviewer contributions and issue recognition through services like Publons.
- Published articles push metadata back to ORCID, keeping author profiles up to date automatically. This benefits authors whose funders require ORCID-linked publication tracking.
- Journals meet indexing requirements — directories like DOAJ, Scopus, and Web of Science increasingly expect ORCID integration. A broken ORCID flow can delay or block index inclusion.
- Co-author disambiguation prevents name collisions. Two researchers named “J. Smith” publishing in the same field can be reliably distinguished when each authenticates with their unique ORCID iD.
When ORCID authentication fails after an upgrade, none of these workflows function. The journal still operates, but the author experience degrades and the administrative burden of manually verifying identities increases.
Why ORCID Authentication Breaks After Upgrading to OJS 3.5
The most important thing to understand is that ORCID functionality changed fundamentally between OJS 3.3 and 3.5. In earlier versions, ORCID support was a separate plugin — the ORCID Profile Plugin — that was installed and configured independently. Starting with OJS 3.5, ORCID is integrated directly into the core application. The old plugin is deprecated and will not receive updates for OJS 3.5 or later.
This architectural shift creates several points of failure during an upgrade:
- API credentials are not automatically migrated. The ORCID API client ID and client secret that worked under the old plugin architecture need to be re-entered in the new site-level settings panel. The upgrade process does not carry these forward.
- Redirect URI configuration has moved. In OJS 3.3, the ORCID redirect base URL could be overwritten via a setting in
config.inc.php. As noted in PKP issue #12267, this override mechanism was not ported to the 3.5 core integration, which means journals that relied on a custom redirect URI may find the OAuth callback pointing to the wrong URL. - User-level ORCID data may be inconsistent. The specific PHP error reported on the PKP Community Forum leads to the system being unable to find the user ORCID record when trying to store OAuth tokens after a successful ORCID login. This can happen when ORCID records from the old plugin era do not map cleanly to the new core data structure.
- Site-level settings override journal-level settings. OJS 3.5 introduced a new administrative layer under Administration > Site Settings > Site Setup > Settings > ORCID. A site administrator can now set global ORCID configuration that overrides individual journal settings. If these site-level settings are incomplete or incorrect, they will silently break ORCID for every journal on the installation.
How to Fix ORCID Authentication in OJS 3.5
Below is a step-by-step verification checklist. Work through each section in order — the most common fixes are listed first, and later steps build on earlier ones.
1. Verify ORCID API Credentials
The first thing to verify is whether the ORCID API credentials are still valid and correctly entered.
- Log in to the ORCID Member Portal (or the public API section if using public credentials).
- Confirm that the client ID and client secret are active.
- Make sure the correct environment is in use: ORCID provides a Sandbox environment (sandbox.orcid.org) for testing and a Production environment (orcid.org) for live use. Using sandbox credentials on a production journal will cause authentication to fail, and vice versa.
- Re-enter the credentials in OJS under Administration > Site Settings > Site Setup > Settings > ORCID.
2. Check the Redirect URI
The OAuth 2.0 flow requires that ORCID redirects back to exactly the right URL on the journal after the user logs in. If the redirect URI does not match, ORCID will reject the callback.
- In OJS, the redirect URI path is
/orcid/authorizeOrcid. Confirm the journal’s base URL is correct under Settings > Journal > Masthead. - If the journal runs behind a reverse proxy or uses a custom domain, make sure the proxy passes the correct host header. A mismatch between what OJS considers its own URL and what ORCID sees will break the handshake.
- Note: if the
orcid_redirect_base_urloverride was previously used inconfig.inc.phpon OJS 3.3, that setting no longer exists in 3.5. Ensure the redirect URI is derived from the journal’s configured base URL instead.
3. Reconfigure Site-Level ORCID Settings
Navigate to Administration > Site Settings > Site Setup > Settings > ORCID and confirm the following:
- ORCID API type: Select “Member API” if your institution has ORCID membership, or “Public API” if using the free tier. Using the wrong API type will cause scope errors.
- Client ID and Client Secret: Re-enter these even if they appear to be present. The upgrade may have left stale or empty values.
- Environment: Verify that Sandbox vs. Production matches the credentials in use.
- ORCID display options: These do not affect authentication itself but confirm the module is configured end-to-end.
If the site-level settings are blank, ORCID auth will fail for every journal on the installation.
4. Clear Cache, Sessions, and Browser Data
After reconfiguring the credentials:
- Run the OJS cache clear command from the terminal.
- Clear the template cache under
cache/if managing the server directly. - Ask affected users to clear their browser cache and cookies for both
orcid.organd the journal’s domain. The PKP support team specifically recommended this step when diagnosing the reported error. Residual OAuth state from the old plugin version can interfere with the new core handler. - Test in a different browser or a private/incognito window to rule out client-side state.
5. Test the Full Authentication Flow
Before declaring the problem fixed, run through the complete ORCID authentication flow:
- Log out of OJS and ORCID completely.
- Log in to OJS as a test user.
- Go to the user profile and click “Create or Connect your ORCID iD.”
- Log in to ORCID in the popup window and authorize the connection.
- Confirm that the browser redirects back to OJS without error.
- Verify that the ORCID iD now appears in the user’s profile as authenticated.
If the error still occurs, enable PHP error logging and check for a stack trace similar to the one reported on the PKP Forum. The location AuthorizeUserData.php:157 pinpointed the exact function that was receiving a null value, which helped the PKP team identify the fix area quickly.
Common ORCID Error Messages After Upgrade
Different configurations produce different error messages. Here are the ones reported by journals after upgrading:
| Error Message | Likely Cause |
|---|---|
| Call to a member function setVerifiedOrcidOAuthData() on null | User ORCID record not found in the database. Check that ORCID data migration completed during upgrade. |
| An authorization code must be supplied | Redirect URI mismatch or stale OAuth state. Clear browser cache and verify the base URL. |
| 500 Internal Server Error on the ORCID authorize callback | API credential misconfiguration at the site level, or the redirect URI does not match the registered callback URL. |
| ORCID appears in profile but is unauthenticated during submission | Auth tokens not transferred from user profile to author record. This is tracked in pkp-lib#12476; check the PKP issue for the current status. |
Testing ORCID Authentication Before Going Live
If planning an upgrade or managing a journal that has already upgraded and needs to verify ORCID before opening to users:
- Use the ORCID Sandbox environment. Register separate sandbox credentials through the ORCID Member Portal and test the full flow against
sandbox.orcid.orgbefore switching to production. - Create a dedicated test user in OJS with a sandbox ORCID account. Run through the profile connection, submission, and publication workflows.
- Monitor PHP error logs during testing. A silent failure in the browser often leaves a clear stack trace in the server logs.
- After testing, switch to production credentials and repeat the test once before announcing the upgrade is complete.
If your journal uses OJS 3.5 and needs a professional, well-maintained theme that handles post-upgrade configuration smoothly, the Noble Theme from Open Journal Theme provides reliable compatibility and regular updates. For journals that prefer a clean, modern academic layout, Classy is a popular choice among OJS publishers. Setting up a fresh installation? The OJS theme collection is built and tested against the latest OJS releases.
About the Author
Open Journal Theme Team — We build and maintain professional themes for OJS, OMP, and Eprints. Our team stays current with every PKP release so journal managers can focus on publishing, not troubleshooting.
