I can generate the access JWT token with client_credentials specified and with the correct scope, but the JWT token is rejected by APIs that the token definitely has the scope for.

{"code":401,"message":"Unauthorized; scope does not match"} 

Validated the decoded JWT's scope and it should be right. Is 3LO required even when assigning an OAUTH app the correct scope on the developer portal and generating a JWT token with the correct scope?

My use-case is a service to service integration and I just came upon this, I can't believe Jira does not support this yet. This is crucial for lots of integrations

• It would enable secure, machine-to-machine communication without relying on personal access tokens, which is crucial for automated backend processes.

• It allows for more granular control over permissions, enhancing security by limiting access to only what's necessary for the application.

• It aligns with common enterprise security policies that prohibit the use of personal credentials in autonomous server applications.

• It simplifies integration compared to alternatives like Forge, which require additional technology stacks, new API layers, and deployment to different cloud environments.

• It reduces development overhead and complexity for teams that simply need to make REST API calls to Jira from their existing backend services.

• It provides a standardized OAuth 2.0 approach that's consistent with other major platforms, making it easier for developers to implement and maintain integrations across different services.

I have an back-end application running in AWS. It reads some events and based on an internal logic times to times it decides to create new Jira issue (or update some existing issue). It already works well for me with my Jira personal access token.

I want to replace my personal access token by some other impersonal token, because of:

• I should not be the creator of these issues. They are not created by any real user, but the backend application.
• I also do not want to give to the backend application all permisions, which I have as a user in Jira. For the backend application it is enough to create and update issues in two projects.
• It is also against our internal company policy to use personal credentials for autonomous server applications.

Now it is possible only via custom made Forge application which is overkill, because to be able to call existing Jira REST API with impersonal token, I need to:

1. Introduce new technology (JavaScript) to our technology stack (my apps are written in Go, but Forge app needs JavaScript).
2. Build new intermediary layer which define new API (web-triggers) and translate it to the existing JIRA REST API.
3. Implement the authentication on the new API (web-triggers) myself.
4. Deploy this new component (the Forge app) to different cloud (Jira cloud instead of AWS which is our company standard) using different process.

It is too much work for simple REST API call