Create own JSM customer portal via a React App

Hello Developer Community :wave:,

I have a question regarding Jira Service Management (JSM).

Me and my team want to build a customer service portal for our customer and as a first component we want to integrate a ticket management application. Because of that we considered using JSM.

We have seen that it is possible to customize the portal of JSM. But the problem is that the customizability isn’t enough for our project. We want to be completly free regarding the design and logic of the portal. Because of that our goal is to create the portal by ourselfs via a React App so that we can also integrate other functionalities which are maybe not related to JSM. (Hopefully the attached image will help to understand our use case; it shows one screen of the design of the react app)

We already had a look at the REST API documentation of JSM and Jira and did some experiments with the API to find out if we can fulfill our use case with the REST API.

During these experiments we encountered some problems with the authorization.

Our first approach was using OAuth2 which is recommended in the developer documentation https://developer.atlassian.com/cloud/jira/service-desk/oauth-2-authorization-code-grants-3lo-for-apps.

But the problem with OAuth2 is that it isn’t working with customers.

We also tried using OAuth2 which Users (Atlassian Account) without a licence for JSM. This also didn’t worked. The OAuth2 flow only worked after giving the Users a JSM licence. But this not suitable solution for us because the application will be used from a lot of customers/users from different companies and therefore this solution would be quite expensive.

Our second approach was using Basic Auth Basic auth for REST APIs. With this approach it would be possible to use the REST API.

But the downside of this approach would be that we need a backend application which is responsible for executing the REST API calls with a kind of super user (for example agent/admin user in JSM and all REST API calls will be done with this account).

Also another downside would be that we would need a kind of user management of our own.
With user management I mean that we have to store user informations (especially the user credentials) somewhere so that the user can login via our frontend. After that we have to make a mapping of the logged in user to the customer which is used in JSM so that the backend can make a REST API call/request in behalf of the customer via the super user.

Maybe a third option would be Atlassian Access. We haven’t made experiments with it yet and we are not really sure if this is a suitable approach for our use case.

To summarize: Our question would be if it makes sense to use JSM if we want to build the portal by ourselfs and not use the “out of the box” portal from JSM. Or is this something which was never done before and therefore is quite risky especially because this use case is not really covered by JSM? It would be also very interesting if someone has already done this so that there is a kind of proof of concept.

If it is possible to use JSM for our use case the we would have the follow up question which authorization approach would you recommend.

I hope that I provided all the necessary informations about our use case and our problems. If not then please let me know. I will then respond as soon as possible.

Thank you very much :+1:

Yes. That is a known issue: [JSDCLOUD-4065] Enable OAuth for JIRA Service Desk customers - Create and track feature requests for Atlassian products.

Please watch, vote, and comment.

I can save you the work. Atlassian Access provides no solution for API client authentication and authorization.

The 1 way you haven’t tried is Atlassian Connect. While documentation will certainly give the impression that it is for customizing the existing UI, Connect offers a JWT authentication mechanism to both Jira platform and JSM REST APIs, that would allow for both user and app auth. This is often how Atlassian Connect is used when building integration to external products like Slack. In effect, the Connect App will act more like a “web proxy” from your app to Jira.

That said, this option is highly complex because Connect’s JWT auth does not provide good means for your portal to perform login or signup. And because it makes your app completely (or heavily) responsible for appropriately handling security of your portal.

In my usual work advising developers, I would recommend against both using Atlassian Connect for this purpose, and the idea of complete rewrite of the JSM portal front-end. You explained, “We want to be completly free regarding the design and logic of the portal.” While potentially a reasonable idea in the abstract, that is far from true for Jira; Jira imposes many design and logic constraints already. There is a lot of overhead in rewriting so many Jira UI components and navigating the obscure logic of Jira issues and workflow. Here are some of the places I know where the complete freedom would become incredible development burden:

  • Description and comments. These fields are treated by the portal as plain text but the underlying issues use Atlassian Document Format.
  • Undocumented field types. For ITSM specifically, the ability to populate asset data is still not fully documented or supported.
  • Attachments. Maintaining proper security around attachments is quite difficult because the media APIs are not fully documented & supported for the portal.

I’m not saying it’s impossible. There are Marketplace Apps that are replacements to the out-of-the-box portal (including some mobile apps). Hopefully, this response helps you understand the trade-offs and make a better decision.