ASP.NET Core 的身份验证中间件是否总是对 OpenID Connect 使用隐式流？

Question

在 Visual Studio 2019 中设置一个简单的开箱即用 ASP.NET Core MVC 应用程序并启用针对 Azure Active Directory 的身份验证，将导致在使用 OpenID-Connect 时隐式 OAuth2 流。

此处说明了这一点。

我刚刚对此进行了测试，并且不必处理授权代码流所必需的客户端机密，因此我认为上述情况属实。

另一方面，在文档中不鼓励使用隐式流：

隐式授权比其他授权带来更多风险，[...] 如果您正在开发包含后端的 Web 应用程序，并从其后端代码使用 API，则隐式流程也不适合。

更令人困惑的是，有此文档说明网络应用程序正在使用授权代码流：

OAuth 2.0 授权代码流在 OAuth 2.0 规范的第 4.1 节中描述。它用于在大多数应用程序类型中执行身份验证和授权，包括 Web 应用程序和本机安装的应用程序。

出现的问题是

• 如果隐式流被认为是一个糟糕的选择，为什么 ASP.NET Core MVC 中间件使用它？
• 我可以改变行为吗？
• 如果是，我可以在哪里以及如何从 Azure AD 的应用程序注册中获取客户端机密？

Answer 1

不幸的是，你的观察是有效的。

提供的示例使用隐式流。为了简单起见，我想。这可以从最新示例的配置脚本中看出。

所有关于隐式流的陈述都是正确的。包括评论里的那句话。

不过需要注意的是，使用 OpenID Connect 的 ASP.NET Core 项目默认的脚手架实际上只进行了身份验证，并没有进行授权。它也不执行对外部 API 的调用。从这个意义上说，隐式流仅用于获取id_token，但不是access_token。前者包含用户个人资料信息，不会带来安全风险。而后者包含访问特定资源的授权数据。所以id_token本身泄露时不会带来安全风险。是的，如果泄露的话，它会造成数据泄露，但不是安全泄露。

这里有更完整的示例。它使用 ob 代表流来调用access_token外部服务。它仍然不是完整的授权码盛大流量，而是代流量。后者更加安全。

一般来说.NET Core中的OpenIDConnect实现确实有处理授权代码的实现，这可以从AuthorizationCodeRecieved事件中看到。通过定义OpenIDConnectEvents 属性来构造OpenIdConnectOptions对象时可以使用它。

坦率地说，询问项目脚手架为何如此设计不会引起太多关注，也不会改变它。我很确定旧的实现（.net 4.5 左右）默认使用 AuthZ 代码。不知道为什么会发生这种变化 - 可能是为了降低实施和理解示例的摩擦....

但是，嘿，在我看来，使用授权码来获取 ID 令牌有点过分了，不是吗？

处理评论

1）同意这是一团糟。Authorize 属性除了检查经过身份验证的用户外什么也不做。它还可以配置为检查特定角色。但即便如此，该角色也将从id_token. 因为你没有access_token网络应用程序。我的观点是，当你处理一个简单的 Web 应用程序（前端、后端 - 控制器或 ASPX 页面）时，你只处理 id_tokens 而没有访问令牌。在这种情况下，隐式流程可以显着降低代码复杂性。

该文档在 GitHub 上开源，任何负责任的程序员都可以自由（并且更受欢迎）提出改进建议或指出问题。而 StackOverflow 是用于技术问题和解答，而不是针对软件文档的投诉。