基于Windows Server 2016 AD FS 4.0实现外部Web应用的OAUTH JWT与共享密钥认证

首先直接给你结论：不需要额外搭建Web服务，除非你的SaaS应用是纯前端无后端架构（这种情况才需要中间层帮你隐藏敏感信息）。下面是针对你当前卡住的核心排查步骤，都是AD FS对接时的常见坑：

1. 先检查Token端点URL是否正确 #

你提到的https://hostname//adfs/oauth/token有两个问题：

• 多了一个冗余斜杠（hostname//应该是hostname/）
• AD FS 4.0的OAuth2 Token端点路径是/adfs/oauth2/token，不是/adfs/oauth/token
  正确的端点应该是：https://hostname/adfs/oauth2/token

2. 确认Token请求的参数和格式完全正确 #

AD FS的token接口要求严格的POST请求格式，必须包含以下参数（Content-Type为application/x-www-form-urlencoded）：

• grant_type=authorization_code （固定值，指定授权类型）
• code=你获取到的授权码 （注意授权码只能用一次，过期时间很短）
• redirect_uri=和你发起授权请求时完全一致的回调URL （AD FS会严格校验这个地址，哪怕差一个斜杠都会失败）
• client_id=你在AD FS应用程序组里配置的客户端ID
• 如果你的应用是Confidential Client（SaaS一般都是这个类型），还要加上client_secret=你配置的共享密钥

举个curl测试的例子（你可以在能访问AD FS的机器上先验证）：

curl -X POST https://hostname/adfs/oauth2/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code&code=YOUR_AUTH_CODE&redirect_uri=https://your-saas-app.com/callback&client_id=YOUR_CLIENT_ID&client_secret=YOUR_SHARED_SECRET"

3. 排查AD FS的配置是否遗漏 #

• 确认你的应用程序组在AD FS里启用了OAuth 2.0 Authorization Code Flow
• 检查应用的权限配置：是否允许获取id_token和access_token（如果你的SaaS用JWT的话，主要是id_token）
• 确认客户端类型设置正确：如果用共享密钥，必须设为Confidential Client

4. 网络和错误信息排查 #

• 确保你的SaaS应用后端能正常访问AD FS的Token端点：有没有防火墙、代理拦截？可以先在后端服务器上telnet测试端口是否通畅
• 如果请求返回错误，一定要看响应的JSON内容：AD FS会返回明确的错误码（比如invalid_grant表示授权码无效/过期，invalid_client表示客户端ID或密钥错误），根据错误码针对性解决

特殊情况：纯前端SaaS应用 #

如果你的SaaS是纯前端（没有后端服务），那确实需要搭建一个简单的Web中间层来处理Token请求——因为不能把client_secret暴露在前端代码里。这个中间层只需要接收前端传来的授权码，然后用后端身份去AD FS请求Token，再把JWT返回给前端即可。

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