API 2.0: authorization for /activities/update always fails

[Ivan Masar]

All I was able to authorize is the "/authenticate" scope. Whenever I try to request authorization for "/activities/update" on sandbox via the 2.0 API, it reports "Invalid scope". I tried both from Google OAuth playground and via curl with the same result. My client ID is APP-U5LLQCW33OX4QL72.

When I request Scope: /activities/update

It redirects me back to:

https://developers.google.com/oauthplayground/?error=invalid_scope&error_description=Invalid%20scope:%20/activities/update&scope=/authenticate%20/read-public

The procedure I'm using is according to the documentation (which uses v2.0 URLs) at

https://members.orcid.org/api/tutorial/update-orcid-records

and the scope should also be valid as per the API 2.0 docs:

https://github.com/ORCID/ORCID-Source/blob/master/orcid-model/src/main/resources/record_2.0/README.md#add-record-items

Regards,
Ivan Masár

[Peters, Robert]

Hi Ivan,
You are using a public client, which has a limited set of functionality (for a comparison: https://orcid.org/organizations/integrators/API). If you are trying to develop a member integration please see http://members.orcid.org/api/introduction-orcid-member-api about receiving member credentials.

Cheers,
Rob

Robert Peters

Technology Director at ORCID.org

Cellphone: +1.805.440.9056

Email: r.pe...@orcid.org

Skype: rcpeters

Timezone: PST
PGP/GPG/OpenGPG key: https://keys.mailvelope.com/pks/lookup?op=get&search=0x1519F37D99E18378

--
You received this message because you are subscribed to the Google Groups "ORCID API Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orcid-api-users+unsubscribe@googlegroups.com.
To post to this group, send email to orcid-api-users@googlegroups.com.
Visit this group at https://groups.google.com/group/orcid-api-users.
For more options, visit https://groups.google.com/d/optout.

[Ivan Masar]

Okay, figured it out - that was a completely unnecessary stumble...

Turns out I was using a client ID which I registered by logging in and going to https://sandbox.orcid.org/developer-tools

When I tried with the client ID that I requested via https://orcid.org/content/register-client-application-2 , it worked just fine.

So it's not just scopes that are public/member, it's also client IDs. Who would have thought? The error (invalid scope) doesn't make that clear, either (unless you already know that you can't use the member API which doesn't allow that scope).

I'm only sorry that I have sunk hours into this problem.

I'll add my thoughts regarding public/member client IDs:

1) I think it's counterproductive to only allow members to register for member access into sandbox. Even non-members could develop integrations using the sandbox.

2) https://sandbox.orcid.org/developer-tools is a handy interface to show properties related to your client ID (app name, description, URL, redirect URIs). It's a pity that it doesn't work with member client IDs, too.

3) There should preferably be one way to request a client ID. The developer tools interface is nice, I suggest you just use that for both public and member client registrations (and show which type of client ID it is!).

I hope my comments help improve this for others who could run into this problem in the future.

P.S. It's not the first time I ran into non-transparent client ID types. With the ScienceDirect API, you get just a string, too and have no idea (and no way to check) what kind of authorizations they attached to it. I hope they improved theirs since I last checked.

Regards,
Ivan Masár

[Wilmers, Catalina]

Hi Ivan,

Thanks for the feedback!

So you know, we allow anyone to register for member credentials to the sandbox- you don't have to be a member to get them. But anyone getting sandbox member credentials has to apply using the form at https://orcid.org/content/register-client-application-sandbox and the credentials will be issues by our team.

Also, one of our goals for this year is to add new tools to make it easier for members to manage their own credentials, like we have now for public clients. I'm not sure we'll go so far as having a single place to request a client for either the public or member API, but I'll pass along the suggestion.

Best,

-Catalina