有保护“Web API”的有效案例，并且您不应该放弃对 Web API 的基本授权（因为即使没有 View，恶意用户仍然可以访问 API。）因此，您最终需要授权访问前端视图和后端 API。
但是，为了防止用户访问特定模板，您需要在Authorize您希望保护的“MVC 控制器”或“操作方法”上应用属性，以便为您的模板提供服务。听起来好像您的客户端框架直接从 Web 服务器获取文件（而不是激活 MVC 控制器操作来接收视图。）
如果您不通过 MVC 控制器提供模板，则需要一些替代方法来保护模板（例如 OWIN 中间件，是的。）
就个人而言，我建议使用 MVC 工具来获得纯粹的便利和未来的持续支持。但是，如果您没有任何 MVC 控制器，OWIN 将是更合适的解决方案（例如，当所有逻辑发生在 SPA 和 API 之间时，不需要 MVC。）
为此：
当我使用剔除或角度创建单页应用程序 (SPA) 时，我通常将所有模板移动到部分模板中。然后我使用 MVC 视图和控制器操作来传递这些部分。
这允许我授权访问我的模板。这也允许我根据仅服务器端的知识修改发出的模板内容，无论是安全性还是其他数据。例如，我有时会User.IsInRole()根据用户角色在模板中包含/排除内容（例如，发出一个为管理员用户提供管理员操作的模板，并为普通用户发出相同的模板但没有管理员操作。）
根据 SPA 的大小和复杂性，我通常在单个页面加载（单个 MVC 视图）中交付整个 SPI。这与假设模板来自服务器的框架不兼容（而不是说，一个元素在当前的 DOM 中），但是它为用户提供了非常快速的体验，并且根据我的经验，相当复杂的 SPA 的大小仍然小于一些最常见的 javascript 框架。
如果应用程序的复杂性或 SLA 需要，我可以分批交付 SPA 的部分（多个 MVC 视图，作为常规应用程序导航的一部分按需拉入浏览器）。例如，~/Home/Index 本身可能会提供整个应用程序使用的所有共享模板，但 ~/Account/Index 可能会提供帐户管理视图，而 ~/Uploader/Index 可能会提供资产上传视图。除非我打算使用这些功能，否则我实际上不需要将这些额外的 Account 和 Uploader 模板拉入应用程序。
TL：博士？使用 MVC 控制器来交付包含您的模板的 MVC 视图，并将该[Authorize]属性应用于任何需要限制为授权/经过身份验证的用户的控制器或操作。为简单起见，考虑使用 MVC 视图来交付整个 SPA，并进一步考虑使用 MVC 部分视图来帮助组织标记，您应该有类似 ~/Home/Index 之类的东西，它只不过是Html.Partial调用的集合（没有实际的标记。）
也就是说，现在你已经让我的装备开启了纯 OWIN 解决方案。如果 SO 上尚不存在这种方法，我将在下周左右尝试使用纯 OWIN 方法进行更新。
希望有帮助。