【问题标题】:Azure web api authenticationAzure Web API 身份验证
【发布时间】:2016-02-13 05:40:10
【问题描述】:

我想通过 3rd 方提供商(FB、G+...我基本上只需要一个有效的电子邮件)来保护我的 Azure WebApi。正在查看 Auth0,似乎它会在 web api 项目中与 Jwt 中间件配对,但我想知道是否只能使用 Azure 来完成。

Azure Web App 身份验证让我有点困惑 - 它似乎没有为我的 Asp.Net Web 应用程序提供任何帮助。我仍然需要在 Startup.cs 中配置所有中间件,如果我完全关闭身份验证,应用程序仍然可以正常工作。

我可以做与 Auth0 相同的事情 - 根据来自 FB 或 G+ 的访问令牌发布我自己的 Jwt 令牌 - 但我想避免这种情况。

能否请您指出正确的方向?

【问题讨论】:

    标签: azure asp.net-web-api


    【解决方案1】:

    你有几个选择:

    应用服务认证

    应用服务身份验证不需要您的应用程序中的任何代码,因为您的应用服务具有检查授权请求的网关。根据设置,您可以保护整个站点或保护单个资源(通过在 MVC/WebAPI 的端点上使用 [Authorize] 属性)。

    使用最新版本,您可以逐个站点控制授权,包括通过将用户导航到<yoursiteurl>/.auth/login/<provider> 来手动触发登录。默认情况下,令牌存储已启用,因此您可以向 <yoursiteurl>/.auth/me 发出请求并从提供者处取回信息。

    中间件认证

    这是在单页 ASP.NET 模板中进行授权的默认方式。中间件身份验证使用 OAuth/OpenId 来保护资源。此选项在应用层而不是在网关处执行此操作。如果您使用的是 ASP.NET Identity(来自单页项目模板),则来自人员登录的电子邮件将自动存储在用户表中。上面链接中的教程提供了有关如何使其工作的许多详细信息。

    确保在任何一种情况下都使用[Authorize] 属性来触发授权。

    希望能帮助您朝着正确的方向开始。

    【讨论】:

    • 这可能是 ASA 尚未与 Asp.Net Core 一起使用 - 主体未传递给应用程序。第二个选项涉及令牌生成,我想在我的应用程序中避免,因为令牌服务器已从核心中删除,现在推荐的方式是使用 3rd 方 IdentityServer。
    • 我会将此标记为答案,因为如果不是 Asp.Net Core,第一个选项显然会奏效。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-07-24
    • 1970-01-01
    • 1970-01-01
    • 2020-07-27
    • 2017-09-05
    • 1970-01-01
    • 2018-07-25
    相关资源
    最近更新 更多