OAuth2.0 vs Basic Auth for Node.js Lambda


I have an AWS Lamba (Node.js) that needs to fetch data from Jira Cloud via the Jira Software Cloud API when triggered on an ad-hoc basis.

We’ve been told by another team it is best for us to authenticate with OAuth2.0 as it’s most secure and the Basic Auth Documentation does say the same. However, the Jira Cloud Documentation for OAuth2.0 (3LO) isn’t clear on how to do this for an application that has no Web UI element.

Please can we have some guidance on how to set up OAuth 2.0 for a Node.js Lambda to be able to authenticate itself in order to the access? Many thanks


It is possible but I advise against OAuth for this scenario. Implementing the authorization code flow would introduce a lot of state management that would make the Lambda far more complicated. And, while you could execute the authorization flow without a Web UI, there is a future problem of re-authorization. While you can get a long-lived refresh token, I’m pretty sure even that cycle eventually expires (I think 1 year) so that a person must re-authorize. So, in addition to state management, there’s some user notification that must be built in so that a person responds and re-authorizes within 15 minutes.

Since you are already using Node.js and Lambda, have you considered Forge instead?

Thanks for your response! That makes sense.

We have not considered Forge yet. Would it definitely be applicable in our situation?

The Lambda in question already exists, and currently fetches data from our Jira Sever instance. We now want to extend it to fetch data from both Jira Cloud and Jira Server.

Would Forge work for an Lambda that we are not building from scratch?


Forge is often a good replacement for Lambda; mainly because Forge is built on top of Lambda. That said, Forge is much more than just a Functions-as-a-Service. It provides a lot of capabilities that run inside the Atlassian infrastructure. But that’s also where some of the caveats would come from. A Lambda running in your AWS account can be granted permissions to things that would be much harder for Forge to reach.

That’s not unusual. Many apps from Marketplace do have shared code & infrastructure across Cloud & Server. However, my standard advice is to treat the 2 as if they were different products. The REST APIs have been diverging for many years now and will only grow further apart going forward.

No. Forge is not intended to be “drop in replacement” for Lambda. They are similar enough that a Lambda could be ported to Forge with small effort, but not zero. And, Forge is Cloud only.

I’d still suggesting having a look at Forge. Even if it’s not the right fit for this project at this time, it’s an important tool for customers.

Back to your original line of questioning, I would recommend the API token with Lambda. You could reconsider OAuth 2.0 if/when Atlassian implements the client credentials flow, which would be more appropriate to this “system to system” style of integration.

1 Like