我在 IBM 云上有一组 REST 服务。Ingress 与 Appid 集成进行身份验证。Ingress 将令牌 ID 和访问 ID 添加到授权标头中。现在在 API 端（springboot）我需要在每个请求上再次验证用户吗？这会是多余的吗？如果没有，可以使用哪个appid api来授权用户。对类似示例的任何引用
已经浏览了 IBM 云站点上的示例。一个是关于 ingress 和 appid 的集成，但没有讨论 REST 服务层如何处理那里的授权令牌。另一个只讲spring和Appid，（不讲ingress）
身份验证与授权是画线的地方。与 App ID 的 Ingress 集成为您进行身份验证，您的 REST 服务（应用程序）可以确保通过的请求经过身份验证。现在仅仅因为用户存在于您的系统中并提供了正确的凭据并不意味着他被允许访问他试图访问的服务或查看他试图查看的数据，这是授权发挥作用的地方 - REST服务可以使用授权令牌来确定用户是否有权使用该服务。
这是一篇关于角色使用的好文章 - https://cloud.ibm.com/docs/services/appid?topic=appid-tutorial-roles
在任何应用程序中 - REST、UI 或其他 - 根据您的要求，可能需要多个安全级别。身份验证验证用户是他们声称的身份，授权检查用户可能拥有的权限。每个应用程序可能对用户可以访问的内容有自己的规则。
在您的情况下，您已经使用 AppID 通过 Ingress 对用户进行了身份验证，该 AppID 为您的应用程序提供了用户主体（身份）。但是，每个用户都应该有权访问您的所有应用程序端点吗？如果答案是否定的，那么您将需要一个授权模型，其常用方法是 RBAC（基于角色的访问控制）。
即使没有 RBAC 要求，以某种形式为每个请求验证用户的主体仍然是明智的。例如，用户可能属于您可能不期望的域，或者不应再有权访问此特定 REST 应用程序。您的应用程序服务器可能具有帮助您使用简单授权功能的功能，或者您可以自定义构建自己的验证。
目前，作为身份提供者，AppID可以作为RBAC用户角色的存储。但是，您的应用程序或应用程序服务器必须决定如何处理该角色。
如果您正在寻找以云为中心的授权解决方案，您可能需要考虑探索 Istio 的授权策略：