将连接的应用程序的作用域限制为一组对象的最佳方法是什么?我目前的解决方案是使用Manage user data via APIs作用域，但仍然授予比所需更多的访问权限。
我经常看到的一个解决方案是创建一个具有受限配置文件的用户并与该用户连接，但这样你就失去了用户在连接的应用程序中所做的操作的上下文，所以这个解决方案不起作用
很棘手，你通常不会。(考虑在https://salesforce.stackexchange.com/上发帖，可能有一个我没想到的聪明方法)。
您可以从"所有用户都可以自我授权"中翻转连接的应用程序;管理员批准的用户是预先授权的。然后只允许某些配置文件/权限集使用该应用程序。但它的大部分是"只是"。通过API启用连接并将其切割为只说Chatter或OpenId标识符。与SOAP api相比，这已经是一个改进了，在SOAP api中，你没有作用域，应用程序可以完全模拟用户，做他们在UI中可以做的一切。
配置文件/权限集/共享规则"即使在不明显的情况下，如照明连接Salesforce到Salesforce或命名凭据访问另一个组织。
如果你不能限制配置文件的可见性和对所有用户可以看到的表的访问，这是不可接受的…
- 你可以创建一系列Apex类，暴露某些查询、更新等，并授予这些类的配置文件访问权限——但没有完整的api访问权限?您甚至可以让它们通过任何SOQL(邪恶)，但在返回结果 之前对表使用
- 您可以查看https://developer.salesforce.com/docs/atlas.en-us.238.0.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm，尽管我怀疑它只在连接时运行，而不是在每个请求上运行。所以如果用户有权查看某些敏感数据，你最多可以拒绝访问，这不是很好。
- 如果有几个对象，你需要阻止更新，如果通过app - quidity可能是走的路。如果动作从REST上下文开始，在触发器中抛出错误?
- 让事务安全先行一步。如果它看起来很有希望(有办法检查"应用程序");和"查询实体";根据这个)-可能是一个解决方案。不过，上次我检查了一些很酷的事件监控功能，你可能不得不掏$ $。交易安全性隐藏在额外的付费插件(独立或与平台加密和现场审计跟踪捆绑到Salesforce Shield解决方案中)
- 2登录?用于查询内容的专用用户，但作为最终用户运行的插入/更新?
with sharing, WITH SECURITY_ENFORCED, stripInaccessible+自定义限制。