OpenIdDict - Disable redirect on "connect/authorize" for XHR requests

Question

I am using openIdDict's sample MVC application to implement the authorization code flow. However, I have an angular 6 app that I'm using for the landing page the user uses to authorize the request. I've got all the angular stuff working but when I submit my request to "connect/authorize" it is generating a 302. The 302 is being caught by the browser and the redirect is occurring, but I do not want that. I want the request to come as a 200 and then the angular app can control the redirect from there.

Reasons I want to do this: 1. The system I'm integrating with requires additional query string parameters to be populated in the redirect (state * others). I want my angular app to populate those and NOT connect/authorize. 2. The angular app will give the user additional instructions/information after they allow the authorization but before the redirect occurs.

My questions are this: 1. Is it possible to change the response code being generated by openiddict? 2. Am I way off track here and making this harder than it should be?

Startup.cs config

            services.AddOpenIddict()
            .AddCore(coreOptions =>
            {
                coreOptions.UseEntityFrameworkCore().UseDbContext<ApplicationDbContext>();
            })
            .AddServer(serverOptions =>
            {
                serverOptions.UseMvc();

                serverOptions.EnableAuthorizationEndpoint(oauthOptions.AuthorizePath)
                .EnableTokenEndpoint(oauthOptions.TokenPath)
                       .EnableLogoutEndpoint(oauthOptions.LogoutPath);

                serverOptions.AllowAuthorizationCodeFlow()
                       .AllowPasswordFlow()
                       .AllowRefreshTokenFlow();

                serverOptions.SetAccessTokenLifetime(new TimeSpan(0, oauthOptions.AccessTokenLifetimeMinutes, 0));
                serverOptions.SetRefreshTokenLifetime(new TimeSpan(0, oauthOptions.RefreshTokenLifetimeMinutes, 0));

                if (!oauthOptions.RequireSSL)
                {
                    serverOptions.DisableHttpsRequirement();
                }

            });

Answer 1

I decided to write my own middleware that would intercept the 302 request being generated by Identity and replace it with a 200 request with a JSON body. I'm sure this can be simplified and maybe I'm just missing something big and I'm way off course. The bottom line is this solution allows someone to implement the authorization code flow using ajax.

Startup.cs

    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        //put this before any other middleware runs
        app.UseMiddleware<AuthorizeRequestMiddleware>();
        ...
    }

AuthorizeRequestMiddleware

public class AuthorizeRequestMiddleware
{
    private readonly RequestDelegate _next;

    public AuthorizeRequestMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        context.Response.OnStarting(AuthorizeStartingHandler, state: context);

        // Let the middleware pipeline run
        await _next(context);
    }

    private Task AuthorizeStartingHandler(object context)
    {

        HttpContext httpContext = (HttpContext)context;
        if (httpContext.Request.Path.HasValue && httpContext.Request.Path.Value == "/connect/authorize")
        {
            httpContext.Response.StatusCode = (int)HttpStatusCode.OK;
            AuthorizationCodeResponse responseBody = new AuthorizationCodeResponse(httpContext.Response.Headers["Location"][0]);
            httpContext.Response.WriteAsync(JsonConvert.SerializeObject(responseBody));
        }

        return Task.CompletedTask;
    }
}

AuthorizationCodeResponse This is my own class. You can make the response look however you want.

public class AuthorizationCodeResponse
{
    public AuthorizationCodeResponse(string redirectUri)
    {
        this.RedirectUri = redirectUri;
    }

    public string RedirectUri { get; set; }
}

Answer 2

There's only one case where OpenIddict will transparently do that: it's when you explicitly enable request caching:

services.AddOpenIddict()
    .AddCore(options =>
    {
        // ...
    })

    .AddServer(options =>
    {
        // ...
        options.EnableRequestCaching();
    });

When enabled, this feature stores the authorization request in IDistributedCache and replaces the authorization request parameters by a single request_id parameter, that is used to represent the request. For that, it indeed uses a 302 redirect.

If you don't like this behavior, simply don't call options.EnableRequestCaching() in the OpenIddict server options.