Add the ability to specify custom headers in the auth redirect response

[AlstonLin]

Is your feature request related to a problem? Please describe.
This feature request will solve a problem we're currently experiencing when the SSO is used for a cross-origin backend server.

Suppose you have the following
api.example.com - This is an API server
app.example.com - This is a web app that performs cross-origin requests to api.example.com

Both are placed behind the SSO proxy. Thus, in order for any requests to be performed to api.example.com, the user must already be signed into the sso-auth service.

The issue is when app.example.com is loaded for the first time, the following occurs

• Request to app.example.com is sent to sso-proxy, the user is not authenticated, so is sent to the SSO sign in page
• After the user signs in successfully, they are redirected back to app.example.com where the HTML page is successfully sent to the browser and the web app begins to render
• During rendering, the web app (app.example.com) sends a cross-origin request to api.example.com. As the user has never loaded api.example.com, there is no session cookie for that request and is thus redirected to sso-auth

This is where the problem occurs, ideally what happens is

• sso-auth sees that the user is already signed in and will redirect them back to api.example.com with the session cookie

But what occurs is

• The request to sso-auth is blocked by the browser, as the preflight response from api.example.com (which is performed by sso-auth) does not include the appropriate Access-Control-Allow-Origin header.

Describe the solution you'd like
There's many possible solutions to this, from more general to specific we can

• Add the ability to configure headers to add to all sso-auth redirects through environment variables
• Add the ability to configure headers to add to all preflight requests to sso-auth through environment variables
• Add the ability to configure the Access-Control-Allow-Origin for the redirect responses by sso-auth

Describe alternatives you've considered
All alternatives are also described above. The currently workaround is to directly visit api.example.com before visiting app.example.com, so the session cookie is set for when app.example.com sends a request to api.example.com.

Additional context
Add any other context or screenshots about the feature request here.