4. 授权码模式详解

授权码模式（Authorization Code Grant）是OAuth 2.0中最安全、最成熟的授权流程，特别适用于EDI报文传输中涉及第三方EDI服务商或企业自建应用访问受保护API的场景。该模式通过引入“授权码”作为中间凭证，确保访问令牌（Access ）仅在服务端之间直接交换，避免令牌暴露在用户浏览器或客户端环境中。

4.1 授权码完整流程

授权码模式涉及四个核心参与方：资源拥有者（企业用户）、客户端（EDI应用）、授权服务器、资源服务器（EDI API）。完整流程分为以下七个步骤：

1. 客户端发起授权请求：EDI应用将用户重定向至授权服务器的授权端点，携带 response_type=code、client_id、redirect_uri、scope 及可选的 state 参数。
2. 用户认证并授权：资源拥有者在授权服务器上登录，并确认授权给客户端访问指定资源。
3. 授权服务器返回授权码：授权服务器通过重定向将授权码（Authorization Code）发送至客户端指定的 redirect_uri。
4. 客户端使用授权码请求令牌：EDI应用后端服务器使用授权码，向授权服务器的令牌端点发起POST请求，携带 grant_type=authorization_code、code、redirect_uri、client_id 及 client_secret。
5. 授权服务器验证并颁发访问令牌：授权服务器验证授权码、客户端身份及重定向URI，返回 access_、_type、expires_in 及可选的 refresh_。
6. 客户端使用访问令牌调用API：EDI应用在HTTP请求头中携带 Authorization: Bearer {access_}，访问EDI API资源。
7. 资源服务器验证令牌并返回数据：资源服务器验证令牌有效性，返回EDI报文数据。

4.2 重定向URI（redirect_uri）

重定向URI是授权码模式中至关重要的安全参数，它决定了授权码和后续令牌的接收端点。在EDI场景中，重定向URI必须是预先注册且完全匹配的HTTPS地址。

4.3 授权码交换与访问令牌颁发

授权码交换是授权码模式的核心安全环节，发生在客户端后端与授权服务器之间，使用直接POST请求完成，不经过用户浏览器。

4.3.1 授权码交换请求

POST /oauth/ HTTP/1.1
Host: auth.edi-platform.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic base64(client_id:client_secret)

grant_type=authorization_code
&code=abc123xyz789
&redirect_uri=https://edi.mycompany.com/oauth/callback
&client_id=edi-app-001

4.3.2 访问令牌响应

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "_type": "Bearer",
  "expires_in": 3600,
  "refresh_": "def456ghi789",
  "scope": "edi.read edi.write",
  "edi_org_id": "org-98765"
}

4.4 适用EDI场景分析

授权码模式在EDI报文传输中具有广泛的应用场景，尤其适合以下典型情况：

• 第三方EDI服务商集成：企业使用第三方EDI平台（如Cleo、IBM B2B Integrator）处理与贸易伙伴的报文交换，第三方平台需要代表企业访问内部EDI API。
• 企业自建EDI门户：企业开发内部EDI管理门户，员工通过浏览器登录后，门户后端代表用户调用EDI API进行报文上传、下载和状态查询。
• 移动EDI应用：移动端EDI应用通过授权码模式获取令牌，实现安全的移动报文审批和实时跟踪。
• EDI API网关集成：在API网关（如Kong、Apigee）前部署授权服务器，所有EDI API请求先经过授权码模式认证，再路由至后端EDI服务。

4.5 授权码模式与EDI报文安全对照