IdentityServer 4, OpenIdConnect redirect to external sign-in url

Kiran picture Kiran · Aug 2, 2017 · Viewed 12.4k times · Source

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.

enter image description here

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

Answer

poke picture poke · Aug 2, 2017

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.