我有一个场景，我们有一个Azure多租户应用程序。客户授予我们的服务与Azure AD对话的权限，并使用授予我们的多租户应用程序的授权代码流从他们的Azure AD租户中搜索(用户/AD组)数据。
发布Azure AD设置用户登录到我们的UI，并尝试从他们的AAD租户中搜索用户/组。我们的服务使用授予多租户应用程序的授权来调用AAD API。
现在，如果客户的AAD管理员通过登录到他们的AAD控制台来删除对我们的AAD多租户应用程序的访问，当我们的服务尝试调用AAD API来搜索用户时，AAD开始抛出http 403(禁止)。
对于这个特定场景，应该向UI返回哪些http状态代码？我们想通知用户这一点，以便他们可以恢复我们的多租户应用程序的授权。
我不认为返回http 4xx是个好主意。如果我们从UI的预期来看，这不是客户端错误。
我认为这是某种服务器错误。我们的服务到AAD的连接由于缺乏授权而中断。
对于这种情况，请从5xx系列或4xx系列中建议一个合理的http状态代码。
状态代码的4xx(客户端错误)类表示客户端似乎犯了错误。除了响应HEAD请求时服务器应该发送一个包含对错误情况，以及它是暂时的还是永久的条件
有效载荷是向最终用户传达实际问题的主要方式。
HTTP状态代码是元数据；目标受众是参与消息交换的通用组件。在网络上，有效载荷是为人类提供的；状态代码用于浏览器、缓存、蜘蛛等等
在您的情况下，请求是可以的。特别是，客户无法改进结果。所以4xx应该是不可能的。
状态代码的5xx(服务器错误)类表示服务器意识到自己犯了错误或无法执行请求的方法。
5xx类的状态代码远不如4xx类的具体(主要是因为其他组件无法采取纠正措施)。
真正的选择是
- 500内部服务器错误
- 503服务不可用
Service Unavailable很有趣，因为它定义了一堆Retry-After语义；您可以向通用组件传达问题何时可以解决的估计，然后这些组件可以判断如何处理这些信息。
503(服务不可用)状态代码表示服务器由于临时过载，当前无法处理请求或定期维护，经过一段时间后可能会有所缓解延迟
因此，如果你认为你可以在事情重新开始之前估计延迟，那么503可能是有意义的。
500(内部服务器错误)状态代码指示服务器遇到无法实现的意外情况请求。
这是一个非常令人满意的替代方案。"我们现在出乎意料地破产了"。
同样，5xx响应的有效负载可以用于向客户端传达更具体的语义。
您应该使用4xx。
HTTP 403是通过HTTP服务器，指示通过客户端由于某种原因被禁止。
最终，您的应用程序达到了不允许当前用户执行某些操作的状态。根据您的普通用户的技术熟练程度，您可以向她提供或多或少的技术信息。既然你似乎能够定义什么是错误的，你就有机会告诉用户这件事以及她应该如何反应。在我看来，那时不需要HTTP代码。把它交给用户并没有真正的好处(除非她技术熟练)。因此，我会在UI中给出一个很好的解释(也许还有一个小字体的文本，其中包含HTTP代码)。但这只是我的看法，我会怎么做。
最后，这还取决于您使用软件实现的业务流程。因此我建议您向负责软件背后业务部分的人员(如产品所有者)提问。如果你有经验的话，询问你的用户体验设计师也是个好主意。