IdentityServer 4,OpenIdConnect重定向到外部登录URL [英] IdentityServer 4, OpenIdConnect redirect to external sign-in url

查看:293
本文介绍了IdentityServer 4,OpenIdConnect重定向到外部登录URL的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试构建多个小型ASP.Net核心Mvc服务,这些服务连接到使用IdentityServer4构建的身份服务器.

我已经在看起来像这样的MVC服务上设置了OpenIdOption

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationScheme = "Cookies"
});

app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions
{
    AuthenticationScheme = "oidc",
    SignInScheme = "Cookies",

    Authority = "http://localhost:5000",
    RequireHttpsMetadata = false,

    ClientId = "mvc",
    ClientSecret = "secret",

    ResponseType = "code id_token",
    Scope = { "api1", "offline_access" },

    GetClaimsFromUserInfoEndpoint = true,
    SaveTokens = true
});

其中,http://localhost:5000是运行我的身份服务器的端点.说如果我的MVC服务器位于http://localhost:5002,我看到当我为控制器设置[Authorize]属性时,它将重定向到我的身份服务器,并且如果检查失败,它将在http://localhost:5002/signin-oidc处查找登录页面

现在我遇到的问题是,我希望登录页面由我在http://localhost:5000/signin-oidc托管的Identity Server托管,因此所有MVC服务都只是利用此身份来获取用户身份,但是不幸的是,我无法了解如何设置此RedirectUrl.

我知道该图在参考流程方面的工作方式是不准确的,只是试图简化我想要完成的工作:)

有可能做到这一点吗?

问候 基兰

解决方案

您似乎误解了/signin-oidc路由的用途.一般流程如下:

  1. 用户访问ASP.NET Core网站.
  2. App要求默认的身份验证方案"Cookies"进行身份验证.

    1. cookie身份验证处理程序尝试从(签名的)cookie信息中恢复身份.
    2. 由于缺少cookie,Cookie身份验证失败.

  3. App要求默认质询方案"oidc"执行身份验证质询.

    1. OpenIdConnect身份验证处理程序重定向到OpenId Connect身份验证提供程序,这是您的Identity Server.
    2. 用户成功登录Identity Server.
    3. 用户被发布到/signin-oidc,这是OpenId Connect身份验证处理程序的远程登录地址.
    4. OpenId Connect身份验证中间件处理/signin-oidc路由,并从Identity Server发出的登录请求中检索用户信息.
    5. OpenId Connect身份验证方案创建身份验证票证,并要求配置的登录方案登录用户.

  4. Cookie身份验证方案处理登录过程并创建用户身份.它将身份存储在cookie中,因此可以在以后的请求中检索该身份,而不必再次经历整个身份验证质询管道.
  5. 用户已登录.

因此,/signin-oidc端点是返回到应用程序以完成OpenId Connect身份验证流的登录过程的方法.到用户到达该地址时,他们已经在Identity Server上登录,并将其重定向回应用程序以继续原来保留的位置.

通常,用户在该路由上花费的时间极少,因为它会在登录请求处理后立即重定向回适当的"应用程序路由.

因此,不会,这里将没有登录表格.登录过程本身是您的OpenId Connect身份验证提供程序(即Identity Server)的责任.这就是要点,所以例如使用您的Google凭据在google.com上安全登录,而不是使用my-random-and-probably-untrusted-app.example.com安全登录,这绝对不能保留您的实际Google凭据.

I am trying to build multiple small ASP.Net core Mvc services that connect to a Identity server built using IdentityServer4.

I have setup the OpenIdOption on the MVC services that looks like this

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationScheme = "Cookies"
});

app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions
{
    AuthenticationScheme = "oidc",
    SignInScheme = "Cookies",

    Authority = "http://localhost:5000",
    RequireHttpsMetadata = false,

    ClientId = "mvc",
    ClientSecret = "secret",

    ResponseType = "code id_token",
    Scope = { "api1", "offline_access" },

    GetClaimsFromUserInfoEndpoint = true,
    SaveTokens = true
});

where http://localhost:5000 is the endpoint on which my Identity server is running. say if my MVC server is at http://localhost:5002 I see that when I set a [Authorize] attribute to the controller, it redirects to my identity server and if the check fails, it looks for the signin page back at http://localhost:5002/signin-oidc

Now the issue I have is that I wan the login page to be hosted by my Identity Server hosted at http://localhost:5000/signin-oidc so that all the MVC services just make use of this to get user identity, but unfortunately I am unable to see how to set this RedirectUrl.

I know the diagram is inaccurate in how it works with reference to the flow, just trying to simplify what I want to accomplish :)

is it possible to accomplish this ?

Regards Kiran

解决方案

You seem to misunderstand what that /signin-oidc route is for. The general flow works like this:

  1. User visits the ASP.NET Core site.
  2. App asks the default authentication scheme, "Cookies", to authenticate.

    1. The cookie authentication handler attempts to restore the identity from the (signed) cookie information.
    2. Cookie authentication fails because cookie is missing.

  3. App asks the default challenge scheme, "oidc", to perform an authentication challenge.

    1. OpenIdConnect authentication handler redirects to the OpenId Connect authentication provider, this is your Identity Server.
    2. User logs in successfully on the Identity Server.
    3. User is POSTed to /signin-oidc which is the remote sign-in address for the OpenId Connect authentication handler.
    4. OpenId Connect authentication middleware handles the /signin-oidc route and retrieves the user information from the sign-in request that was made by Identity Server.
    5. OpenId Connect authentication scheme creates the authentication ticket and asks the configured sign-in scheme to sign in the user.

  4. Cookie authentication scheme handles the sign-in process and creates the user identity. It stores the identity in a cookie, so it can be retrieved on future requests without having to go through the whole authentication challenge pipeline again.
  5. User is signed in.

So the /signin-oidc endpoint is the way to return back to your application to complete the sign-in process of the OpenId Connect authentication flow. By the time the user reaches this address, they have already signed in on the Identity Server and they are being redirected back to the application to continue where they originally left off.

Usually, the time the user spends on that route is minimal since it will redirect back into a "proper" application route immediately after the sign-in request has been processed.

So no, there will be no login form here. The login process itself is the responsibility of your OpenId Connect authentication provider, your Identity Server. That’s the whole point about this, so you e.g. login securely on google.com with your Google credentials instead of on my-random-and-probably-untrusted-app.example.com which definitely should not get hold of your actual Google credentials.

这篇关于IdentityServer 4,OpenIdConnect重定向到外部登录URL的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆