I would appreciate any pointers to get me started.
:: Background ::
I would like to build an app for Confluence which will inject authenticated content from our own SaaS service into the Confluence page when requested (via a macro). This is somewhat akin to the Google Drive Confluence app that can embed a Google document into a Confluence page when given a link to such a document.
:: Question ::
We are going to build the app using Atlassian Connect since we will want it in the Atlassian marketplace down the line. So we host the app. How can we authenticate who the user is that is invoking the app so we can decide whether to show them any content and if so which based on what the user is authorized on our service?
I’ve read two types of docs that are related but work in the opposite direction:
Docs about how to make the app impersonate a given user.
Docs about how our app can use OAuth to be able to make REST APIs against Confluence.
Neither applies here. I appreciate pointers for how to know in our app who the Confluence user is.
Thank you,
Jad
@jad welcome to the Atlassian developer community.
In the context of a macro, you can use the Connect JavaScript API to determine who is the current user. This is in the front-end where the macro will be rendered in the Confluence UI. The front-end should probably pass to a correlated back-end that would translate from the world of Atlassian users to the world of your users, in order to make requests authenticated to your SaaS service.
Much appreciated. In that flow, would there be some token that our front-end can receive from the Connect Javascript API, and send to our backend to properly validate the user, say either by calling the Atlassian authorization service or by verifying a signature with a shared secret with Atlassian? Otherwise we have to worry about request spoofing from our front-end.
The reason I am asking is that the alternative would have to be for us to develop a full signed-in experience to match the Confluence user with who they are on our side (e.g. an oauth flow on our side) and I want to see if it can be avoided. Thanks again.
Yes, Connect sends a JSON Web Token (JWT) with a special query-string hash claim to make sure the request isn’t spoofed. You can use this in front or back to validate a user. That said, I understand the pain of multiple auth flows; however, I don’t know if you can use Atlassian Connect’s JWT to fully avoid the OAuth flow your side unless you have some other means to associate Atlassian user accounts with your system.