Service Provider Workflow

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.

This workflow requires ORCID API version 3.

Token delegation
Secure sharing
Enabling the workflow
Technical documentation


When a member adds or updates items on an ORCID record on behalf of another member to, they must get permission to do so from both the member and the researcher -- the record-owner.   Benefits include:

  • Single authentication step. Researchers only need to grant permission once to update their record, to the member organization they originally interact with, which then transfers that permission to the service provider. Researchers do not need to grant permission to the service provider directly, saving them time and making the process easier for them
  • See the source of connections with ORCID records. Following our principles of transparency and openness, we believe it is important to be able to see the source of the assertion -- who is adding what information to a record
  • Proof of authentication and delegation. There is transparent and built in-assurance that the researcher’s ID has been authenticated by the original member organization, and that they have authorized the service provider to act on their behalf 
  • Simple integration for delegating members. Members can use a simple, ORCID-created javascript wizard to gather and share permissions

This is how the source of the information is displayed in an ORCID record: 

Delegating permissions

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.

  1. The researcher logs into the manuscript submission system to submit their article
  2. 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)
  3. 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 
  4. 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 
  5. 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
  6. 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

Notes: In the workflow, the manuscript submission page for the journal may be managed by the journal itself or by the service provider. In either case the web page must implement a simple OpenID connect authentication workflow, such as embedding our javascript widget or directly implementing the javascript (our example is only 34 lines long!)
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.

Secure sharing

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 and have their client enabled.  

This functionality is enabled by default in our API 3.0. To opt out and prevent others redeeming your identity tokens, please contact ORCID Support

Technical documentation

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.