Summer break technical post: ORCID OAuth with passport.js12 Aug 2016 | By Daniel Nüst, Jan Koppe
With the University in a rather calm state during summer, the o2r team continues to work on the first prototypes for testing and demonstrating our ideas. This is the first post on a technical topic, and we will occasionally write about topics that are not related to the scientific work but either kept us busy for some time or might be useful to others.
Last week o2r team member Jan struggled with the implementation of the login feature for a Node.js microservice. Why would we bother with that? Because we want to share our prototypes publicly and invite you to try them out, but at the same time not have to worry about one of your most valuable possessions: your password.
Therefore we decided early on to rely on three legged OAuth 2.0 for handling user authentication. We opted for ORCID as the authorization server because it is the most widespread identification for researchers today1, and because of the potential for useful integrations in the future2.
The solution3 required to dig a bit deeper into the code of the used libraries, namely passport.js with the plugin passport-oauth2. Jan summarizes everything nicely in this Gist and the working implementation is part of our component o2r-bouncer. The ORCID support team was even so kind to include our solution on their code examples page and we shared it with the ORCID API Users mailing list in the hope that future developers will find this information helpful.
So in the end, a full day of work to figure out two missing lines of code, but still many days saved on bullet-proofing standalone authentication and password storage.
The used libraries would allow us to quickly add more authorization services, such as Google or GitHub. ↩
Wouldn’t you like to have a research container be automatically added to your publication list? ↩
In a nutshell, the
passReqToCallbackoption must be enabled when creating the
OAuth2Strategyand the used callback function must include 6 arguments. Only then the function with the largest number of arguments is used and the content of the accessToken-request answer, which includes the ORCID id and user name, is accessible in your own code. They can be found in the
paramsparameter of the function, not as part of
profileas one is used to with other OAuth servers. This seems to be a slight deviation from the standard by the ORCID folks. ↩