Organization API Tokens Take 2

[mrowles]

Describe the solution you'd like
We would love to generate, manage and use Organization API Tokens rather than our own User API Tokens since we do a lot of AppCenter CLI work through our CI/CD.

App Tokens are not enough, as we use the token to build apps dynamically based off env etc.

Describe alternatives you've considered
We have a generic user account atm who has access to the organization, but there are some security concerns.

Additional context
We hopefully can use this via the CLI (request raised here): microsoft/appcenter-cli#1030 (comment)

[mrowles]

Feature raised here last year, but was auto-closed and suggested I re-raise this if we still want it: #1971

[wisdeom]

Thanks for your feedback. With the nature of Org API token, we'll have to evaluate the feature from different angles such as security aspects and RBAC permissions, etc. We'll look into this idea, but, unfortunately, can't guarantee to grab this work any time soon. Appreciate your feedback once again. We'll leave this open for the time being!

[mrowles]

It was actually a feature that auto closed already.

It’s generating API token to deploy apps that are apart of the same org. Isn’t it best practice? Right now we have to generate these for a single user, which is a single point of failure. If anything, there is more security concerns with user accounts, even if just generic accounts.

More than happy to help how we can, just keep us posted please :)

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[mrowles]

I still want this, please.

[slarti-b]

My issue on the app-center-cli github has been merged here.

I'm not fully convinced that my request is exactly the same as this. It's similar, but is more limited. I do not necessarily want org-level tokens (although that would be better than user tokens for automated usage). I see the advantage in them for other use cases, but it's not my first choice of solution here. My use case is this:

• I have one or more apps on my organisation.
• I want to define some groups (e.g. "Internal Testers") at the org level, rather than repeating the setup for each app and having to keep them in sync.
• For each app I want to automate distribution, including being able to distribute to an org-level group if it is already connected to the app.

The last point is key - currently it fails to distribute to org-level groups if I use an app token, so I have to use a user token. While I can certainly see use-cases for org-level tokens, I actually actively want to have a token that is restricted to just that app! I would use an org token over a user token, if that's the solution proposed, but in keeping with the "minimal privileges" principles I'd prefer to stick with app tokens. I think it's wrong that a CI system simply automating a deployment has to run as some individual user, when it isn't - and also then it has to have much more privileges than it should (unless you do a lot of admin with users per app in some way).

So my request is simpler: if the distribution group is connected to the app already, then you can distribute to it with an app token, whatever level the group is defined at. This seems a much simpler thing: it seems like a permissions check that needs updating rather than a whole new type of token.

To be honest, I really feel that this is a bug: the admin has connected the distribution group to the app so I should be able to distribute the app to that group with an app token. But I understand this was a deliberate limitation, so I raised it as a feature request.

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[slarti-b]

I still want at least the minimal scope in my comment above. This should really be considered as a security-related bug, in my opinion! The current limitations force us to use an over-privileged user for our CI system. However, given it was a design choice to do it this way it's here as a feature request.

@wisdeom: Any news? You merged my request here, I fully understand why (it's similar) but I do feel the scope somewhat exploded in the process :)