ORCID sign-in is a core component of most ORCID workflows.
Enabling users to register or sign into your system using their ORCID credentials can save them time and effort; they don’t have to keep track of multiple usernames and passwords, and you immediately obtain an authenticated ORCID iD. At the same time as asking users to sign in, you can request permission to read or update their ORCID record.
ORCID sign-in is similar to social sign-in, for example sign-in using Google or Facebook, as offered on ORCID and other websites, and is often refered to as “single sign on” or “SSO”. You place a ‘sign in with ORCID’ button on your page, users click it, users authenticate themselves, and they are then returned to you with information about their ORCID account, including their name and authenticated ORCID iD.
Individuals sign into their ORCID accounts using their registered email address and password or with linked alternate sign-in credentials – this means that users can sign into ORCID with their federated institutional accounts and/or social accounts. Individuals without an existing ORCID iD can create one as part of the sign in process.
ORCID supports:
- OAuth 2.0
- OpenID Connect 1.0
- Multi-factor authentication
See the API Tutorial ‘Get an Authenticated ORCID iD‘ for more details.
ORCID strives to enable transparent and trustworthy connections between researchers, their contributions, and their affiliations by providing a unique, persistent identifier for individuals to use as they engage in research, scholarship, and innovation activities. Ensuring that the correct ORCID iD is associated with the right researcher is a critical step in building the trustworthiness of the ORCID dataset and the broader scholarly communications ecosystem. For this reason, ORCID does not permit the manual collection or entry of ORCID IDs in any workflow where it is possible to collect ORCID IDs directly from record holders themselves.
Researchers can easily and securely share their ORCID iDs with the systems they interact with, which proves they own their ORCID iD. Those systems can then share information about researcher activities with other systems, which creates a chain of validated and trusted assertions about researcher activity. The end result is that the correct person is associated with the correct activities across a broad range of scholarly information workflows.
For more information see: https://info.orcid.org/collecting-and-sharing-orcid-ids/
3
2
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It supplements existing OAuth authentication flows and provides information about users to clients in a well described manner.
OpenID connect is a standardised way of implementing OAuth and sharing information about authenticated users. It will now be possible to configure services to use ORCID “out of the box” alongside other standards compliant OpenID connect providers. OpenID connect also provides sharable ID tokens, which are signed objects that can prove a user authenticated using ORCID at a specific time. These tokens can be used by user interface elements to maintain user sessions.
ORCID supports the Basic OpenID Provider conformance profile, which is an extension of the OAuth authorization code flow. ORCID also supports the implicit token flow for the “/authenticate” and “openid” scopes.
This means that ORCID:
- Embeds signed id tokens within token responses for authorization codes generated with the ‘openid’ scope
- Supports the implicit flow when using ‘token’ or ‘token id_token’ response_types and the ‘openid’ scope.
- Supports the ‘prompt’, ‘nonce’ and ‘max_age’ parameters for authorisation requests that include the ‘openid’ scope.
- Supports Openid Connect discovery and userinfo endpoints
- Supports the ‘amr’ field for integrators using the member API for authorisation requests that include the ‘openid’ scope. This can be used to discover if a user authenticated using two factor authentication.
Initiating an OpenID Connect authentication works the same way as a regular OAuth authentication. All that is required is that the client request the ‘openid’ scope If you are using the /authenticate scope replace it with openid, as authenticate and openid have the same authorization only one or the other should be used. If you are using any other scopes, add openid to the list of scopes requested. When the openid scope is included, the Registry will return an id_token inside the token response and grant the client permission to access the user info endpoint for that user.
ote that the ‘openid’ scope does not start with a ‘/’ like the other ORCID API scopes. This is because the ‘openid’ scope is not defined by ORCID, but instead defined by the OpenID Connect specification.
See our technical documentation for more information.
4
6
ORCID allows users to enable Two-factor authentication (2FA) on their ORCID account. 2FA is a secondary security check made during the sign-in process. It provides additional confirmation that the user is indeed the person signing into an ORCID account. For more information relating to how this can be configured for users please see our KB article.
OpenID connect integrators using the member API can check to see if the user had signed into their ORCID account with 2FA enabled as part of the OAuth process. This can allow member integrators to grant access to their researchers to higher security systems.
2
0