You can't. That's not how HTTP works. First, a "redirect" is just a 301, 302, or (since HTTP 1.1) 307 status code with the Location
header set to the URL the client should go to. It's the client that initiates the request to that URL, so you have no control over what headers they send.
Second, HTTP is stateless, so the fact that an Authorization
header was sent in some response at some point has zero bearing on anything that happens in any future requests. Web browsers and other HTTP clients skirt around the stateless nature of HTTP by using sessions on the server-side and cookies on the client side. The client sends the cookie to the server with the request. The cookie matches an item in the session store on the server, and the server loads up the data from that session to give the appearance as though state was maintained.
Third, cookies don't work in this situation, because they are domain bound and are not sent along with requests to domains they did not originate from. So, even if you were to create session to maintain the authorization, the other site would never see it.
FWIW, the basic premise here, sharing authentication state with a different domain, is exactly what technologies like OAuth were developed for. So direct future research in that direction.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…