Related threads: 1, 2
I am working to get a bot installed proactively for the users in my tenant and in other tenants as well. The proactive installation should happen to every single chosen user starting from the first.
(Currently, I have not published the bot to Teams App Store and either creating new bots for other tenants or publishing the same bot package in other tenants.
But in the context of this issue, the method of publish can probably be ignored as the issue is prevailing in any case because of the lack of support for application permissions for that API.)
As in documentation the first suggested method to get the teamsAppId is using the GET /appCatalogs/teamsApps API.
The second and third methods doesn't sound rational (for my requirement) as,
- they require the bot to have installed already for a user and that should have happened manually, i.e, at least one user should add the bot from store to his/her personal scope for the second method in the documentation to work.
- I am not supporting groups, channels or teams conversations and supporting only personal scope installation.
I am using client credentials flow as the entire process is being governed by a service runner and of course the installation is done for other users as mentioned and guided in the documentation,
So, is there a way to consume the api without user intervention using client credentials flow?
The only other workaround I have is to orchestrate a behavior in which I should use Authorization code grant flow or implicit flow as soon as I get the admin consent for application permissions as a separate process so that I can get a token with delegated scopes on behalf of the same user (the admin) and then can use that token to get the list teamsApp api. This method of using the token issued for a individual user to consume an api i.e, consuming an api as an individual user that gives details of the appCatalog which is the tenant's resource and not specific to that individual user doesn't seem to be logically correct. (This also takes a lot of explanations to make to the clients about the additional process.)
Also, will really appreciate if some light can be shed on the reason why application permissions are not supported for this API as it seems to be the most logical way of doing the proactive installation.