Open aroden-salesforce opened 9 years ago
Or should they be enforced at the API management level (i.e. layer7)?
Yes, it should be enforced at the API management level (my bad). This is a use cases where scopes do not map1to1 with a path hierarchy.
This bug is to think about how the API can opt-in parts within specific authorization scopes.
Specifically I'm concerned around use cases exposed in AppCenter. When a user installs an app we'd like that app to have limited access against the user's account. Further, it should be a meaningful access levels shown the user in a clear request for permission fashion. Of course, the same thing applies the other way, meaningful categories for app developers to opt-into.
@aroden-salesforce I do not believe this is a requirement for 4.0, but please correct me if i'm wrong.
This is actually for the discovery document, where ever that lives (I don't think I see it here, so I don't think it directly applies to this repo).
The "discovery" document should live here but isn't linked to and emphasized enough :(
On Sat, Jun 6, 2015 at 4:11 PM, Douglas Christopher Wilson < notifications@github.com> wrote:
This is actually for the discovery document, where ever that lives (I don't think I see it here, so I don't think it directly applies to this repo).
— Reply to this email directly or view it on GitHub https://github.com/salesforcefuel/SFMC-Fuel-Style-Guide/issues/19#issuecomment-109644400 .
To support oauth scoping effectively routes must provide an indication of the scopes the provide/belong to.
The scopes of these routes will be enforced at a framework level by the granted scope of authentication.