The support.orcid.org website is on a UserVoice platform that has a different privacy policy from our other sites. You may view the details at http://support.orcid.org/tos
X

Register a member API client application

Introduction

Before you can use ORCID's Member API, need to create an API client which will give you login credentials for your application: a Client ID (consumer KEY) and Client Secret (consumer SECRET). Your application will use these credentials as it interacts with the ORCID API.

To obtain client application credentials for the Member API on the production site, you first will need to become an ORCID Member.

However, anyone can try the member API on the ORCID sandbox testing server. To do so, you will register a client application following the instructions below. (Note that this process is not automated and your reply may take up to a couple days to process.)

Filling in the client application form

To get started, fill in the form to register a client application. Below is a quick overview of the requested fields:

  • Fields to make sure we know who you are
    • Notes for ORCID staff: Let us know if you're using a vendor system, need additional redirect URIs, or have any other questions or notes.
    • Name of your organization 
    • Contact email address: We will send the credentials to this address and we will use it to contact you about bugs and important API notifications and updates.
    • Contact for receiving PIN to access credentials: We will send the PIN to access your API credentials to this contact. (production member API only)

  • Fields displayed to users
    • Name of your client application: Displayed on authorization screen and list of trusted organizations. Generally the name of your organization.
    • Short description of your client application: Displayed on authorization screen with question mark icon. A short description of your organization or application.
    • URL of the home page of your application: Displayed on list of trusted organizations. A link back to your organization or the main page of your application.
  • Fields to ensure the correct interactions for your API
    • OAuth2 redirect URIs or callback URLs for this client: Permitted URL(s) in your web application where users would be returned to after they authorize access to their ORCID record data. All redirect URLs must be HTTPS for production (live) server clients. 
Display name and description displayed to users on the authorization page

Display name and website displayed under trusted organizations

What you will receive back

Once you have made your request, a manual process happens to issue you credentials and you will get an email with your client iD and client secret. Typically these requests are process in less than 24 hours.

About redirect URIs

Some larger organizations can have 100s or 1000s of potential callback URIs. In these situations it can sometimes be impractical to register all of them. There are several approaches one could take to manage high numbers of Callback URIs:

  1. Register no redirect_uris at all
    If the client app is configured with no redirect_uris, then any redirect_uri can be used. This is less secure than specifying redirect_uris. The redirect_uris give an extra level of security because they prevent somebody using someone else's stolen client credentials (because we would never redirect to their domain - they would also have to have control over the user's DNS to get round that!). For more on the potential risks here, you may enjoy this short post staring "Evil User": OAuth 2.0 Redirection URI Validation.

  2. Register just the host name
    If the client app is registered with a redirect_uri that is just the host name, then any redirect_uri at that host can be used. So, for example if the following redirect_uri is registered

    https://thirdparty.com

    then all of the following redirect_uris will work

    https://thirdparty.com/oauth/callback1
    https://thirdparty.com/callback2
    https://thirdparty.com:8080/callback
    https://thirdparty.com/anything-else-as-long-as-the-host-is-the-same

    If they need https as well, then that needs to be registered separately. Also, sub domains need to be registered separately, e.g. http://app.thirdparty.com.

    NOTE: If you decide that this approach might work for you - you can perhaps handle the URIs by registering all of the redirect URIs in one of your domains and then redirect again to the appropriate domain.

  3. Register all redirect_uris fully
    This method is encouraged when practical.
All redirect URIs must start with the https prefix on the production server, while http is allowed for testing on the sandbox server. Localhost can be registered as a redirect URI using http://localhost

Feedback and Knowledge Base