ASP.NET Core API PDF端点安全：JWT传递困境及方案咨询

不用被迫单独加Cookie认证，这里有几个更贴合你现有JWT Bearer认证体系的方案：

方案1：通过Fetch获取Blob并动态展示（推荐） #

这个方案不用改动后端的认证逻辑，完全沿用你现有的JWT Bearer验证，同时能让用户在浏览器原生PDF查看器里打开文件。

前端可以通过fetch请求PDF，在请求头里带上JWT，拿到返回的Blob后生成临时URL，再用新窗口或iframe展示：

async function openPDFWithAuth(pdfId) {
  try {
    const jwtToken = localStorage.getItem('your-jwt-key'); // 从你存储Token的地方取
    const response = await fetch(`/api/v1/MyAPI/GetPDF?id=${pdfId}`, {
      headers: {
        'Authorization': `Bearer ${jwtToken}`,
        'Accept': 'application/pdf'
      }
    });

    if (!response.ok) throw new Error('无法获取PDF文件');
    const pdfBlob = await response.blob();
    const blobUrl = URL.createObjectURL(pdfBlob);

    // 打开新窗口展示PDF（浏览器会用原生查看器）
    const pdfWindow = window.open(blobUrl);
    // 页面关闭后释放Blob URL，避免内存泄漏
    pdfWindow.addEventListener('beforeunload', () => {
      URL.revokeObjectURL(blobUrl);
    });
  } catch (err) {
    console.error('加载PDF失败:', err);
    // 这里可以加错误提示，比如弹框告诉用户无权访问
  }
}

把原来的<a>链接改成按钮，点击时调用这个函数就行。好处是Token不会暴露在URL里，完全符合你现有认证流程，代码量也不大。

方案2：使用签名临时URL #

如果想保持纯<a>链接的用户体验，后端可以生成带签名的临时有效URL，用户点击链接时不用传Token，后端通过签名验证请求合法性：

1. 前端先请求后端生成签名URL：传递用户ID、PDF ID和过期时间（比如10分钟）
2. 后端用密钥对这些参数进行签名（比如HMAC-SHA256），把签名、过期时间、PDF ID拼到URL里，返回给前端
3. 前端用这个签名后的URL作为<a>的href
4. PDF端点收到请求时，验证签名是否有效、是否过期，同时检查用户是否有权限访问该PDF

这种方式的好处是用户体验和原来完全一致，而且Token不会出现在任何地方，安全性很高。后端只需要加一个生成签名URL的接口，PDF端点加个签名验证逻辑，不用改动现有JWT认证体系。

方案3：URL参数传递Token（不推荐，但可选） #

把JWT放在URL的查询参数里，比如：

http://localhost:51660/api/v1/MyAPI/GetPDF?id=94a8ea0b-aec9-4812-839f-a2f7f4d0e122&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

后端修改PDF端点的认证逻辑，优先从查询参数里读取Token进行验证。但这个方案有安全风险：URL会被存在浏览器历史、服务器日志里，容易泄露Token，所以只适合临时场景，且必须配合HTTPS使用，同时设置较短的Token有效期。

综合来看，方案1和方案2都是比单独加Cookie认证更简洁的选择，方案1前端改动小，方案2用户体验更接近原来的方式，你可以根据自己的需求选。

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