No, not with 3LO, better known more broadly as OAuth 2.0 authorization code flow. This flow is meant for clients to act on behalf of a user. While there is a related client credentials flow (aka 2LO), the scope of available APIs (known as Open DevOps APIs) would preclude your scenario.
That’s not a specified behavior of our 3LO implementation. Is this something you observed during testing? If so, I would certainly characterize it as a bug.
And, to return to your query from your original post:
Currently, you would find this described as asApp in Forge or Connect. In Forge, your code explicitly specifies asApp. In Connect, your code applies JWT authentication that is effectively asApp by default.
For your integration scenario (you already have a platform), Forge or Connect would act something like an API proxy. This means for either approach, your product must still have a way to auth to the Forge or Connect App. For Forge, that would mean your own auth code behind a web trigger, running in Atlassian infrastructure. Or for Connect, it’s more “anything goes” as a Connect App is basically “you build it, you run it”. That means you could host the Connect App parts within your product so auth is by means of “same process” (inside your infrastructure). Overall, there are few examples of integration via Forge and it is not yet recommended for that scenario. Many SaaS companies like yours have been successful in “system to system” auth using Connect.