IdentityServer4能否在Header返回Access/Refresh Token？是否需切换至Node.js OAuth2？

Hey there! Let's break this down for you clearly.

First off, it's important to note that the OAuth 2.0 spec (RFC 6749) explicitly requires token responses to live in the HTTP response body—that's why IdentityServer4 (and nearly all mainstream OAuth2 implementations) follow this default behavior. So the tokens showing up in the body is totally standard, not a quirk of IdentityServer4.

But if you have a specific business need to move the Access Token and Refresh Token into response headers, you absolutely can make this work in IdentityServer4—no need to jump to Node.js OAuth2 just yet. Let me walk you through how, and why switching frameworks isn't the solution here.

How to Customize Token Response Location in IdentityServer4 #

You have two solid approaches to tweak the response to fit your needs:

1. Customize the Token Endpoint Response Handler

IdentityServer4 lets you replace the default logic that creates endpoint results. You can implement the IEndpointResultCreator interface to intercept token responses, pull the token data, and add it to headers (you can choose to keep the body content or remove it, depending on your needs).

Here's a simplified example of how this might look:

public class CustomTokenResultCreator : DefaultEndpointResultCreator
{
    public override Task ExecuteAsync(IEndpointResult result, HttpContext context)
    {
        if (result is TokenResult tokenResult)
        {
            // Extract token data from the standard response
            var tokenData = tokenResult.Response;
            
            // Add tokens to custom headers (use X- prefixes to avoid conflicts)
            context.Response.Headers.Add("X-Access-Token", tokenData.AccessToken);
            context.Response.Headers.Add("X-Refresh-Token", tokenData.RefreshToken);
            context.Response.Headers.Add("X-Token-Type", tokenData.TokenType);
            context.Response.Headers.Add("X-Expires-In", tokenData.ExpiresIn.ToString());
        }
        
        // Keep the default body response (or modify it here if you want to remove it)
        return base.ExecuteAsync(result, context);
    }
}

Then register your custom handler in your Startup's dependency injection:

services.AddTransient<IEndpointResultCreator, CustomTokenResultCreator>();

2. Use a Middleware to Intercept Responses

A lighter-weight option is to add a custom middleware to your pipeline that catches token endpoint responses, extracts the token data from the body, and injects it into headers:

public class TokenHeaderMiddleware
{
    private readonly RequestDelegate _next;

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

    public async Task InvokeAsync(HttpContext context)
    {
        // Only target the token endpoint
        if (context.Request.Path.Equals("/connect/token", StringComparison.OrdinalIgnoreCase))
        {
            // Capture the original response stream
            var originalStream = context.Response.Body;
            using var tempStream = new MemoryStream();
            context.Response.Body = tempStream;

            // Let the request proceed normally
            await _next(context);

            // Read the standard token response from the body
            tempStream.Seek(0, SeekOrigin.Begin);
            var responseJson = await new StreamReader(tempStream).ReadToEndAsync();
            var tokenResponse = JsonSerializer.Deserialize<TokenResponse>(responseJson);

            if (tokenResponse != null)
            {
                // Add tokens to headers
                context.Response.Headers.Add("X-Access-Token", tokenResponse.AccessToken);
                context.Response.Headers.Add("X-Refresh-Token", tokenResponse.RefreshToken);
            }

            // Write the original body back to the response
            tempStream.Seek(0, SeekOrigin.Begin);
            await tempStream.CopyToAsync(originalStream);
        }
        else
        {
            await _next(context);
        }
    }

    // Helper class to deserialize the token response
    private class TokenResponse
    {
        [JsonPropertyName("access_token")]
        public string AccessToken { get; set; }
        
        [JsonPropertyName("refresh_token")]
        public string RefreshToken { get; set; }
        
        [JsonPropertyName("token_type")]
        public string TokenType { get; set; }
        
        [JsonPropertyName("expires_in")]
        public int ExpiresIn { get; set; }
    }
}

Add this middleware before the IdentityServer middleware in your Startup's Configure method:

app.UseMiddleware<TokenHeaderMiddleware>();
app.UseIdentityServer();

Should You Switch to Node.js OAuth2? #

Short answer: No, there's no need.

Virtually every OAuth2-compliant library (including Node.js options like oauth2-server) follows the spec and returns tokens in the response body by default. If you switch, you'd have to implement the exact same kind of custom response logic you'd build for IdentityServer4—plus you'd have to learn a new framework and rewrite existing code. It's unnecessary extra work for the same outcome.

Important Notes to Consider #

• Breaking the OAuth2 spec like this will mean most off-the-shelf OAuth2 client libraries won't work with your endpoint out of the box. You'll need to modify client code to read tokens from headers instead of the body.
• Stick to custom header names (like the X- prefix used in examples) to avoid conflicting with standard HTTP headers.

内容的提问来源于stack exchange，提问作者Chase