Minimal requirements / documentation for integrating a new Accounts system (OAuth RSA public/private key)



I’m trying to integrate OAuth authentication with a remote JIRA instance. JIRA uses OAuth 1 with an RSA-SHA1 public/private key pair. From reading the Meteor OAuth source code (OAuth1Binding.prototype._buildHeader), I don’t think this is supported because it hardcodes HMAC-SHA1 as the signature method.

There is an NPM package that integrates JIRA OAuth (using the NPM oauth module): In simple tests, I can make this work.

I’m considering building a new account-* style package that uses jira-connector do to the heavy lifting, but which still creates a user and authenticates through the standard meteor machinery.

I’m finding the various accounts-* (and oauth*) packages pretty hard to follow.

Is there any documentation / example that illustrates the minimum set of requirements for building an account system. In theory, “all” I’d need it to do is:

  • Call a function JiraClient.oauth_util.getAuthorizeURL with some fixed parameters to get some data back from JIRA. Basically this returns a URL for the user to visit, a request token, and a token_secret. The latter two need to be stored temporarily (in Session?).
  • Capture a call-back URL (how do I do this without relying on a specific routing solution?) that will include a user key as a URL parameter.
  • Call a function JiraClient.oauth_util.swapRequestTokenWithAccessToken to obtain an accessToken. This needs to be stored in the database alongside the token_secret. With these two I can make whatever future requests using the API I need.
  • Satisfy enough of the Accounts machinery that Meteor.user() and so on work as expected.

Any pointers appreciated!



Here’s a nice library for Instagram which you could model your oauth client to work like:

Hope that helps, it helped me.


This uses the OAuth package to do the heavy lifting. I don’t think that works because the aforementioned lack of support for public/private key authentication in OAuth.


So, much digging hence, I managed to get this to work and published

Code at

The trick was to create a “fake” OAuth version to use the delegate that would normally go to the oauth1 package, but use the jira-connector library instead. Maybe a bit hacky, but seems to work.