我们目前实施的效果很好，但我只是担心可能有更好的方法，或者我们做错了。
登录到我们的网站后，在每个请求中，它都会向 API 发出请求以获取用户详细信息。
例如用户名、ImageUrl、角色/权限、电子邮件地址等
然后它将这些数据存储在 BaseController 中，以供视图页面或其他任何人在该请求期间查看。
好处：
这样做是因为您知道用户权限/角色及其详细信息都是最新的每个请求！
缺点：
您最有可能在每次请求时获得完全相同的数据，直到有一天他们更改了详细信息。因此，您可能会打不必要的电话？
然而，我们尝试所有这些的第一种方法是当用户登录时，他们的所有数据都存储在 cookie 中，问题是我们的用户几乎从不注销，因此存储在 cookie 中的所有数据经常变得陈旧。-> 陈旧的角色/权限是一个烦人的问题！！！
每个人如何从登录中绕过过时的数据。
我会回到您最初将声明存储在 cookie 中的方法。
如果您确实有很长的登录时间，那么我会通过定期刷新 cookie 来防止停滞不前的声明。
如果您使用表单身份验证，那么您可以拦截FormsAuthentication_OnAuthenticateGlobal.asax 中的事件，解密和管理 cookie（此处），首先验证用户和 cookie，然后针对 userdata 属性中的自定义字段（称为 refreshedDate）运行快速条件检查。
如果最后刷新日期或创建日期大于某个可配置窗口，则调用数据库并从数据库刷新索赔数据。最后更新 refreshDate 并声明数据并更新 cookie。
更新
从您的评论开始...
只是说每个请求都访问数据库并不少见，也就是说我知道它发生在许多生产系统中。许多人可能正在使用 MS-SQL 数据库的ASP.NET 会话状态。通常，当确实需要使某人的会话无效，拒绝访问并立即将其注销时，我会看到它。
如果您的数据库位于 Web 服务器本地的网络上和/或延迟很低，那么它可能是一个完美可行的解决方案。只需确保您的数据库查询最小化并且性能调整到完美，考虑将任何 ORM（如果适用）并使用原始 SQL 连接来使事情尽可能快。
如果数据库延迟很高，则另一个中间解决方案是缓存，使用Redis或Memcached来存放查询结果并在更改权限时使缓存失效等……但显然为缓存解决方案添加所需的基础架构和操作支持是一个认真的考虑。
除了其他建议之外，另一种选择可能是在用户数据更改时使用来自底层角色/权限存储的通知机制。然后，此通知可用于使 Web 服务器上的缓存数据无效。这将确保在大多数情况下返回缓存的数据，但只有在数据发生更改时才会访问存储。
如果底层数据存储是 SQL Serevr，那么考虑类似SqlDependency.
这显然是一个更复杂的架构，但它会满足您的要求，只有您才能说它是否值得付出努力/复杂性/权衡！
您可以对 cookie 应用过期时间；这样它就会死掉并要求他们登录。或者，将他们的用户 ID 保留在 cookie 中，但将他们的个人资料信息存储在会话中。当会话终止时，下次检查配置文件是否为空时，再次查询 API。这样，它会更频繁地更新。