Granular Oauth Scopes

[vivekvj01]

Required Terms

• I agree to follow this project's Code of Conduct
• I have read and accept the Salesforce Program Agreement

Current Oath scopes for Heroku is quite Broad and customers need to provide custom scopes to limit the access to Heroku resources.

Eg:
Billing Alarm

As the name suggests, this add-on needs access to the Invoice Info and Team Invoice Info endpoints of the Heroku Platform API through an OAuth Authorization created by a Heroku user.

Currently this can only be achieved by creating an Authorization with the global scope. This is a big no-go for us.

We need the ability for a Heroku user to create an Authorization with a custom set of permissions / scope that allows us to do the above and nothing else.

In a world where cyber security is paramount, fine-grained access control is a relatively simple, but powerful feature.

This would also greatly lower the threshold for Heroku users to integrate with third party applications, because they trust the provided Authorization token can only be used within its limited scope.

[oavanruiten]

@vivekvj01 if I understand correctly, this is an entirely new feature request?

Is there anything to say about if and when this will be picked up?

We are really looking forward to implement this and ship our new add-on.

I am happy to provide more information to clarify our use case.

[vivekvj01]

That is correct @oavanruiten it is a new feature. We do not have a timeline yet but understand the need for this.

[caifara]

This issue has been a concern for at least eight years. It's common to need such authorizations for tasks like programmatic scaling, managing subdomains, and releasing information. However, the current implementation requires applications to use keys that grant access to all of your account details and other apps on Heroku. This creates a significant risk, as one can only hope nothing goes wrong with any of those keys. Simply following best practices for key protection isn't enough because these keys are too powerful.

In this context, the lack of granular scopes is a major security risk waiting for a disaster. Granular scopes would immediately address this issue. Not having a more robust security framework, and not even working on it, seems irresponsible given the risks to customers.

Additionally, in my experience, the non-global scopes are inconsistent. For example, the read scope can't list pipelines or retrieve information about one by name, but it can retrieve details by ID. On the other hand, it allows listing apps but not accessing their release information. The "read" scope, which could solve some problems (if it excluded secrets), behaves unpredictably. Worse, this behavior isn't documented, making the process a frustrating trial and error.

[oavanruiten]

Thank you @caifara for sharing your thoughts. I totally agree.

@vivekvj01 are we closer to getting this implemented?

[vivekvj01]

hi @oavanruiten it is already part of our roadmap and i am working through defining how this would work. However we do not have a timeline yet.