首页 文章

怎么会发生 . Identity Server4用户登录页面重定向 . 重定向网址的目的

提问于
浏览
0

我是Asp.net核心身份和Identity Server 4的新手 . 我正在关注使用Open Id Connect与asp.net核心和身份服务器4实现身份验证的在线培训课程 .

如果我进一步说明我的解决方案有Asp.net核心mvc Web应用程序 client . 另一个asp.net核心mvc网络应用程序为 IDP (Identity Server4) 和另一个asp.net核心mvc web api as resource server .

对于IDP上未经过身份验证的用户登录页面正在出现 . 对我来说问题是客户端网站(asp.net核心网络应用程序)如何知道用户未经过身份验证?我的猜测是用户第一次访问Web应用程序访问令牌没有出现在授权标头上,因此身份验证中间件知道这不是身份验证请求和重定向请求到IDP是否正确?

然后用户重定向到帐户控制器的逻辑视图如何在IDP上配置重定向(我的意思是这里是如何完全重定向到帐户控制器登录页面)?

此外,在IDP上配置RedirectUris(https://localhost:44326/signin-oidc)的目的是什么 . 以及它是如何工作的

顺便说一下,我在这里使用授权代码流和IdentityServer4.Quickstart.UI AccountController来自那里 .

1 回答

  • 0

    要么你知道什么api需要身份验证,因此,如果你没有任何地方可用的令牌,你应该将用户重定向到oauth服务器 . 一旦这个重定向回您的应用程序,您将在URL中找到令牌(如果我的记忆力良好,则为其参数) . 此令牌必须保存在内存中以供以后使用或在应用程序db(标准浏览器功能)中保存 . 然后,您可以使用您存储的令牌调用api .

    如果您不知道api需要身份验证或令牌是否已过期,则无论如何都会调用api,然后您会收到403错误(未经授权) . 任何403错误都应该使客户端应用程序决定在身份验证门户上重定向用户以获取新令牌 .

    当你使用代码流时,我想你必须开发一个react,angular或任何spa应用程序 . 所以我建议你使用oidc-client . 它是一个javascript库,由开发身份服务器的同一个人开发 . 在处理oauth身份验证时,它使客户端的开发变得非常简单 .

    这里有关于完成/使用的过程和检查/变量的更详细描述:

    • 客户端应用程序(javascript / html5)在资源认证http请求标头中没有任何令牌的情况下调用资源服务器

    • 资源服务器(您的api服务器)尝试在标头中获取令牌

    • 不存在 . 这意味着请求未经过身份验证 .

    • 资源服务器在进行任何控制器调用甚至授权检查(角色等)之前向客户端返回403错误

    • 客户端捕获此403错误,然后知道此调用需要一个令牌 .

    • 客户端将失败请求的url及其post(如果适用)存储在应用程序db中

    • 客户端通过传输客户端ID(身份验证服务器的javascript / html5应用程序的标识符),范围(此客户端应用程序在上下文中应使用的资源集),将浏览器重定向到身份验证服务器URL . 此身份验证请求)和身份验证服务器在验证后应重新更新用户的URL .

    • 身份验证服务器要求用户进行身份验证(以任何方式可以想象,但大部分时间都是通过询问用户登录和密码)

    • 如果验证服务器识别了用户(与登录匹配的密码),则会检查返回URL(客户端应用程序传输的URL是否用于在右侧页面上重定向用户)他已经过身份验证)位于此客户端应用程序的授权返回URL列表中( the RedirectUris you are wondering about ) . 这一点的目的是确保发布的令牌不会传输到未经授权的应用程序(就像在中国托管的外部javascript / html5应用程序,它可以找到一种从api服务器中获取某些数据的方法,只有您的用户才能知道并将其提交给俄罗斯api服务器,用户甚至没有注意到它)

    • 它还检查这个客户端应用程序(不是用户......这里是为了确保特定客户端javascript / html5应用程序可以访问一组资源)可以使用的范围请求 .

    • 如果检查正常,则认证服务器通过使用其私钥对其进行签名来发出access_token .

    • 认证服务器通过将url中的access_token设置为参数,在最初发送的返回URL上重定向用户 .

    • 客户端应用程序获取此参数并将其存储在某个地方(任何您想要的地方,但大部分时间都在应用程序数据库和内存中)

    • 客户端应用程序获取为调用存储的url再次完成,但此次使用身份验证头中的access_token

    • api服务器(或资源服务器)再次收到http请求

    • 终于找到一个access_token并检查它是否实际上是由身份验证服务器(使用其公钥)发出的,因为它是唯一可信任颁发令牌的层 .

    • 然后它可以信任令牌中的内容:内部提到的用户ID,允许访问的范围(功能集)等等...

    • 然后它调用控制器并返回响应 . 如果令牌已过期((令牌中的简单日期),则它不会对控制器进行任何调用并返回403 .

    仅供参考,如果其签名已由当时的身份验证服务器完成,则令牌中的任何内容都可以信任 . 该系统可以防止中间安全漏洞的人 . 含义:通过监视网络活动获得令牌的人,更改此令牌内的内容,以便他可以针对您的api服务器进行任何他想要的调用 . 将检测到此令牌中所做的任何更改,因为签名(某种加密哈希)将不再与新内容匹配 . 这个签名,如果每个人都可以使用公钥在世界上检查它,只有一层可以使用其私钥发出它:身份验证服务器 .

    我试图让它尽可能完整,但仍然可以理解为你声称的oauth新手 . 希望这可以帮助 .

相关问题