I am developing a Jira Software integration for the Zoho Cliq platform.
I have a query regarding the dynamic webhook registration. For authentication, we have implemented the OAuth2.0 of Atlassian and enabled all the scopes under the Jira Software configuration.
The issue is that when I register a webhook endpoint to a Jira subdomain manually by going under the advance setting->webhooks I was able to register the webhook without any issue and enable the events at which the endpoint must be triggered but in this integration, I want to register the webhook manually so I referred the Jira dynamic webhook registration docs and used the API call to register my webhook URL with specific events enabled, the webhook registration was successful but I didn’t receive any response to the registered endpoint when the event is triggered and I registered the same URL manually by going under the advance setting → webhooks it works well and I am getting the response to the given endpoint when an event is triggered.
I would like to know why this is happening and why I didn’t receive any response when I registered it dynamically by using the REST APIs (The registration was successful but I didn’t get any response to the endpoint).
later i have come across the above documentation . In this there are many scopes specified for each webhook event type. But the required scopes of the event type is not listed on the developer console to create app for Oauth 2.0 to select. I cannot use the scopes which is not enabled in the developer concole.
Only choose from the scopes that you have already added to the APIs for your app in the developer console.
I have added the requried scopes but still I am not getting any responses when the event happens and webhook is triggered.
Any help/explanation would be appreciated, Hoping to hear from the developer community soon.
Hi Kavya!
This sounds very much like a problem with missing scopes. Note, that Atlassian has recently implemented some changes to the scopes logic and we are in a transition period, so things may be a little bit confusing.
First of all an app must be granted write:webhook:jira scope in order to create a webhook.
But this is not enough for a webhook to be fired. Your app needs also scopes related to data sent by a particular webhook in order to receive it. For the list check here: https://developer.atlassian.com/cloud/jira/platform/webhooks/#using-the-rest-api--registration
I hope it helps,
Adam
Hi @AdamSlaski@ibuchanan sorry for resurrecting this thread, but have some questions that feel highly related to this issue.
I am hitting the exact same issue when registering a webhook authenticated as an OAuth 2.0 app. Specifically, when using an access_token issued with the grant_type: client_credentials. When I register webhooks like that, the POST rest/api/3/webhook registration request returns a 201 status code and the new webhook is available when listing the webhooks with GET, however the registered webhook url gets never hit.
Interestingly, the very same procedure works just fine and the endpoint at the url gets hit when using a token issued for a specific user while registering the webhook, e.g. a token returned when going through the consent screen flow
This leads me to the question: Are dynamic webhooks supposed to be created on behalf of OAuth 2.0 apps or only on behalf of app users? I was assuming that both should work since the examples in the docs here use the Forge mechanism await api.asApp() to register dynamic webhooks. Also in many scenarios it might make much more sense to only register one webhook per site as an app.
Also I would like to confirm: what is the correct way to authenticate “asApp” as an OAuth 2.0 application? There is documentation explaining the consent grant flow for OAuth 2.0 apps to get access_tokens on behalf of a user here, but I couldn’t find docs around how to authenticate “as App”. I assume we could use the “client_credentials” grant type, but would like to confirm that.
Lastly I just hit another interesting issue: in order to reproduce the problem I created a new OAuth2.0 app in the dev console, adjusted our app’s clientId and secret and fired up the app. The user login and consent flow and Jira REST API calls work just fine, however API calls with a token issued via the grant_type: client_credentials (aka. “authenticated as App”) now return the error message: “The app is not installed on this instance”. Also the endpoint https://api.atlassian.com/oauth/token/accessible-resources returns an empty array when called with such “as App” tokens. So my question around this is: how can we make sure that a new OAuth2.0 “gets installed” on a Jira site so that we can perform requests on behalf of the app itself?
That is a lot to process. It sounds like there’s a “happy path” that doesn’t quite work the way you expect so you tried several alternatives and they didn’t work either. But I wasn’t entirely clear on which one was the “happy path” for you. Do you want webhooks to work as a 3LO App or a Forge App?
Sorry for the wall of text, let me boil it down a bit.
I’d like to register a webhook on behalf of an OAuth 2.0 (3LO) app to get notified about relevant issue updates within our app. This doesn’t work for us when using an access token obtained with the grant_type: client_credentials and our app credentials. The configured URL never gets hit by Jira or in other scenarios it returns “The app is not installed on this instance”.
Webhooks that are created with an OAuth 2.0 access token obtained for an Atlassian user e.g. through the consent flow however do work as expected.
So based on those observations it looks like: dynamic webhooks only appear to work when they are created “on behalf” of a user, not “as App” when using OAuth 2.0 (3LO). Is that the expected behaviour or a bug?
I suspect that dynamic webhooks should be working also when created “asApp” (aka. with grant_type: client_credentials) with OAuth2.0 (3LO) since this is how it seems to work for Forge apps as documented in the code snippet here.
Thanks for elaborating. Where I’m really getting confused is on your use of the client credentials flow. I was unaware that Atlassian provided that with OAuth 2.0, except for the Open DevOps APIs. Indeed, client_credentials flow is sometimes known as 2-legged OAuth (2LO) so is not the same as 3-legged OAuth (3LO). Overall, I think it’s not that webhooks don’t work with 2LO; it’s that most endpoints don’t.
Yes, I realize Forge provides a 2-legged authentication with asApp, but that doesn’t mean it’s supported by OAuth 2.0 clients. So, yes, I think it is the expected behavior that webhooks don’t work. Although I think it is unexpected that it doesn’t provide 401 Unauthorized.
Yeah I got confused as well since I couldn’t find any info around how to register a webhook “as an App” when using OAuth2.0 in the docs, there are only examples for Forge or Basic Auth.
It certainly would be a great feature to allow things like webhook registrations “asApp” for OAuth 2.0 apps. This would ensure feature parity with Forge apps in terms of authentication as well.
Is this something that could be considered to land on the roadmap?
