Login page on different domain

public class Startup{    public void Configuration(IAppBuilder app)    {        app.UseCookieAuthentication(new CookieAuthenticationOptions        {            AuthenticationMode = AuthenticationMode.Active,            LoginPath = new PathString("/account/login"),            LogoutPath = new PathString("/account/logout"),            Provider = new CookieAuthenticationProvider            {                OnApplyRedirect = ApplyRedirect            },        });    }    private static void ApplyRedirect(CookieApplyRedirectContext context)    {        Uri absoluteUri;        if (Uri.TryCreate(context.RedirectUri, UriKind.Absolute, out absoluteUri))        {            var path = PathString.FromUriComponent(absoluteUri);            if (path == context.OwinContext.Request.PathBase + context.Options.LoginPath)            {                context.RedirectUri = "http://accounts.domain.com/login" +                    new QueryString(                        context.Options.ReturnUrlParameter,                        context.Request.Uri.AbsoluteUri);            }        }        context.Response.Redirect(context.RedirectUri);    }}

If apps.domain.com is the only return URL base possible, you should strongly consider replacing context.Request.Uri.AbsoluteUri with context.Request.PathBase + context.Request.Path + context.Request.QueryString and build an absolute return URL in your authentication server to protect your apps from abusive redirects.

Hope this helps ;)

EDIT: you might ask yourself why I don't directly apply the redirect using the context.RedirectUri property. In fact, ICookieAuthenticationProvider.ApplyRedirect is responsible of multiple redirects, corresponding to the log-in and log-out flows (yep, I know, it breaks the single responsibility principle...). But there's even worse: context.RedirectUri can either represent the authentication endpoint's absolute URL in the beginning of the log-in flow or the final browser's destination (ie. the real relative "return URL") when the cookie is effectively being sent back to the browser... that's why we need to make sure that context.RedirectUri is absolute and corresponds to the registered context.Options.LoginPath.

I am working through the examples for https://github.com/IdentityServer/IdentityServer3 and I have a different answer. In the example at https://www.scottbrady91.com/Identity-Server/Identity-Server-3-Standalone-Implementation-Part-2 they show an MVC app that uses a standalone IdP and cookies authentication. The example hasn't included getting 401 redirects working, but I stumbled on a way.

The basic scheme is to create an action in the AccountController for logging on.

public ActionResult SignIn() {  // set up some bookkeeping and construct the URL to the central auth service  return Redirect(authURL);}

Now you have a local URL that can be used in the Startup

public class Startup {  public void Configuration(IAppBuilder app) {    app.UseCookieAuthentication(new CookieAuthenticationOptions    {      AuthenticationType = "Cookies",      LoginPath = new PathString("/Account/SignIn")    });}

You also have the added benefit that you can put an action link to the SignIn on the menu bar, for people who want to log on before there is a 401. What we've done here is decoupled the decision of what to do when an unathenticated user asks for a resource from how the authentication is obtained.