ORCID Sign-In / Authentication

ORCID sign-in (also called “Sign in with ORCID” or ORCID authentication) is the OAuth 2.0/OpenID Connect-based process by which a researcher proves ownership of an ORCID iD to a third-party system — a journal submission platform, a funder’s grants portal, an institutional repository, or a CRIS — and, depending on the scope requested, grants that system permission to read or write specific parts of their ORCID record. It is the mechanism, not the identifier: having an ORCID iD means a researcher has registered a persistent identifier; signing in with ORCID means a specific external system has, at that moment, verified the researcher actually controls that iD and (optionally) been granted ongoing access to it.

What makes something an instance of ORCID sign-in

An interaction counts as ORCID sign-in when all three of these are true:

• A third-party system redirects the researcher to orcid.org (directly or in a popup window) rather than collecting an ORCID iD as free-text entry.
• The researcher authenticates at ORCID itself — with their registered email/password, a linked institutional or social sign-in, or a QR-code mobile sign-in — not with credentials belonging to the third-party system.
• ORCID returns the researcher to the requesting system with, at minimum, an authenticated iD, and, if broader scopes were requested and the researcher approved them on ORCID’s authorization screen, an access token the system can use to read or write to the record going forward.

This is the same underlying OAuth grant that CASRAI’s guide to registering, finding, and searching for ORCID iDs describes from the researcher’s side when connecting an iD to NIH eRA Commons, NSF Research.gov, or an institutional system — this entry defines the mechanism itself.

Sign-in-only vs. deeper record access

Not every “Sign in with ORCID” button asks for the same thing. ORCID’s OAuth implementation distinguishes scopes:

• /authenticate (or the OpenID Connect openid scope, which grants the same authorization) — collects the researcher’s authenticated iD and public-visibility record data only. This is what most “Sign in with ORCID” buttons on journal and repository login pages request: proof of identity, nothing more.
• /read-limited — Member API only. Lets the requesting organization read record items the researcher has marked visible to trusted parties rather than the public.
• /activities/update and /person/update — Member API only. Let the organization write new items (works, employment, funding, other-names, etc.) directly into the researcher’s record — the mechanism behind “auto-update,” where a publisher or funder adds a new work to a researcher’s record automatically once granted.

Every scope beyond /authenticate requires the researcher to explicitly approve it on ORCID’s own authorization screen at the time of sign-in — a system cannot silently escalate from “confirm who you are” to “edit your record” without a fresh, visible consent step naming exactly what it’s asking for. Once granted, an access token for /read-limited or the update scopes is long-lived (ORCID’s own documentation states these tokens remain valid for approximately 20 years, or until the researcher revokes them from their account’s “Trusted parties” page), which is why reviewing and pruning that list periodically is a genuine account-hygiene task, not a hypothetical one.

Worked example

A researcher submitting a manuscript clicks “Log in with ORCID” on a journal’s submission platform. They are redirected to orcid.org, sign in with their ORCID password, and see an authorization screen showing the journal’s name and the single /authenticate scope. They approve it, and the platform receives back their authenticated ORCID iD to attach to the submission — no further access to their record is granted, and nothing was written to it.

Contrast this with a researcher connecting their ORCID iD to eRA Commons: the sign-in screen there requests broader scopes so that NIH can subsequently write funding records to the researcher’s ORCID record as awards are made, which is why the authorization screen at that point lists more than identity confirmation and the researcher is explicitly asked to approve ongoing write access, not just a one-time login.

Counter-example: what ORCID sign-in is not

A researcher who types their sixteen-digit ORCID iD into a plain text field on a form — without being redirected to orcid.org to authenticate — has not “signed in with ORCID.” That system has collected an unverified, self-reported iD; it has no way to confirm the person entering it actually controls that identifier, and the researcher has granted no OAuth token of any kind. This distinction matters operationally: an authenticated iD (via sign-in) is treated by funders and publishers as a trustworthy assertion; a free-text iD is not, and NIH’s requirement that senior/key personnel have an ORCID iD “linked” to their eRA Commons profile specifically means the authenticated connection, not a typed-in number.

Common practical issues

• Two-factor authentication (2FA). If a researcher has enabled 2FA on their ORCID account, signing in — including via a third-party “Sign in with ORCID” flow — requires the second factor (an authenticator app code or a saved one-time recovery code) in addition to their password. 2FA is optional but ORCID-recommended; each recovery code is single-use, and losing both the authenticator device and the saved recovery codes means the researcher cannot complete any sign-in, including through a journal or funder system, until ORCID support manually restores access.
• Popup blockers and stale sessions. Because the sign-in screen commonly opens in a popup window, browser popup blockers or an already-open ORCID session logged into a different account are frequent causes of failed or wrong-account connections — ORCID’s own integration guidance for organizations recommends the popup display the full orcid.org address bar precisely so the researcher can confirm they’re authenticating on ORCID’s real domain before entering credentials.
• Confusing “connected” with “public.” Granting a system /read-limited or update access through sign-in does not change what’s visible on the researcher’s public ORCID profile page — visibility (public/trusted-parties/private, per ORCID record permissions) and OAuth access grants are two separate, independently managed layers.
• Duplicate or wrong-account sign-in. A researcher who has forgotten they already registered an iD, or who is signed into a personal ORCID account when they meant to use an institutionally-managed one, can end up connecting the wrong record to a funder or publisher system. This is generally a sign-in-time mistake, not a record-merge problem, and is worth checking before completing the authorization screen.

Related terms

ORCID iD · ORCID record · ORCID record permissions · ORCID API · ORCID consortium

References

• ORCID Inc., “ORCID as a Sign-In Option to Your System” (info.orcid.org).
• ORCID Inc., “ORCID OAuth Sign-In Guidelines” (info.orcid.org).
• ORCID Inc., “Sign In Using ORCID Credentials” (info.orcid.org).
• ORCID Inc., “What is an OAuth scope, and which scopes does ORCID support?” (info.orcid.org).
• ORCID Inc., “Secure your account with two-factor authentication” (support.orcid.org).