This workflow describes how ORCID service provider members can interact with the ORCID Registry on behalf of their clients who are also ORCID members. Service providers include publishing platforms, research information platforms, grant application systems, other cloud-hosted platforms, and other research infrastructure providers.
The workflow is suitable for client-server situations, such as a publishing platform creating article metadata or indexing content on behalf of a journal. In this scenario, the researcher authenticates their ORCID iD and grants update permissions on the member organization’s website, while the service provider provides the more complex functionality to collect information from the ORCID record, connect information to it, and synchronize with their system.
This workflow is also suitable for members with multiple client IDs who want to be able to share permissions between their systems, for example, a university sharing permissions between their CRIS, repository, and HR systems.
In this example, we use a journal submission workflow for the sake of simplicity, but the process is equally applicable to repositories, grant applications, and other workflows delivered via a service provider system. Note that both the journal and the service provider must be ORCID members.
- The researcher logs into the manuscript submission system to submit their article
- The researcher is prompted to authenticate their ORCID iD and grant the journal permission to interact with their ORCID record. ORCID provides the journal with the researcher’s iD and name, and a special identity token that can be used to delegate permission to the service provider (please see Open ID connect for more information)
- The journal authorizes the service provider to update the researcher’s ORCID record, by providing them with the identity token. This could be done alongside another task, such as indexing the article metadata or creating an article identifier
- When the article is published, the service provider uses the ORCID API and the identity token to update the researcher’s ORCID record on behalf of the member, including information about the assertion origin (the journal) and the source (the service provider). This connects the article, journal, service provider, and researcher. See our documentation on token delegation for more info
- The source of the assertion is displayed on the researcher’s ORCID record as “[Service provider name] on behalf of [Journal name]” in both the user interface and the API metadata
- The journal and service provider display the researcher’s ORCID iD in their interfaces where appropriate, for example, in the online version of the article
The identity token can be stored, so the researcher only needs to grant permission to the journal the first time this workflow is used. After that, the existing token can be reused by either the journal or the service provider. The researcher can revoke this permission at any time, although it’s rare that they do so.
The “identity tokens” mentioned in the above workflow contain the date/time of authentication, which ORCID iD was authenticated, and by which ORCID member. Identity tokens can be used as proof of authentication and can be shared with other parties that require that proof. ORCID creates identity tokens in a standards-compliant way, which means they interoperate with existing OpenID connect and OAuth libraries and tools.
Only ORCID members can exchange these tokens for update permissions, and they can only do so over secure https channels, using their client secret. Record updates made with these tokens clearly show who the token was issued to, who made the update, and when.
Enabling the workflow
Members who wish to exchange identity tokens for access tokens and work on other member’s behalf must contact ORCID Support beforehand to discuss their integration and have their client enabled.
This workflow uses OpenID connect to authenticate researchers’ iDs and delegate permissions. OpenID connect provides an id_token, which is a digitally-signed JSON document describing who authenticated the iD, when, and to whom. This token is passed from the original authenticator to a service provider who uses an IETF token exchange mechanism to swap it for an OAuth access_token. This is a simple process, and OpenID technical documentation with examples, as well as a token delegation tutorial are available to guide you through the process.