# 5G核心网SBI接口安全：NRF OAuth2令牌授权与mTLS双向认证全链拆解
## 一、为什么SBI安全是5G核心网安全设计的"分水岭"
4G EPC的核心网网元之间采用基于Diameter/GTPv2/CAP的"参考点（Reference Point）"接口，安全模型以**网络域安全（NDS/IP，IPsec隧道）**为主，默认认为"接口后端可信、边界由防火墙隔离即可"。然而5GC在TS 23.501中引入了**服务化架构（SBA）**：所有网络功能（NF）通过基于HTTP/2 RESTful API的**服务化接口（SBI）**互相通信，并经NRF（Network Repository Function）进行注册、发现与路由。
这一架构转变直接颠覆了传统的安全假设：
- **接口从"封闭私有"变为"开放标准"**：SBI运行在HTTP/2上，任何能到达SBI端口的实体理论上都可构造REST请求，攻击面（attack surface）从专有协议扩大到整个Web协议栈。
- **连接从"点对点"变为"动态发现"**：NF在调用前才通过NRF发现对端实例，传统的"预配置IPsec SA"难以覆盖动态拓扑。
- **授权粒度从"网元级"变为"服务操作级"**：同一个AMF可能需要调用UDM的 `nausf-auth`、`nudm-sdm`、`nudm-uecm` 等多个不同服务，需要细粒度授权。
为应对这些挑战，3GPP在 **TS 33.501《Security architecture and procedures for the 5G system》Clause 13** 中为SBI设计了一套**三层纵深防御**的安全体系，并由 **TS 29.500（SBI技术原则）**、**TS 29.510（NRF协议）** 共同定义了基于 **OAuth 2.0** 与 **mTLS** 的具体信令流程。本文聚焦这一机制——这是5GC安全区别于4G最重要的设计之一，也是当前公众号文章较少系统拆解的"冷门硬核"主题。
## 二、SBI三层纵深防御架构
TS 33.501 Clause 13.1 将SBI安全划分为三个相互独立的防护层，分别对应不同的威胁模型：
```mermaid
flowchart TB
subgraph L3["应用层安全 (Application Security)"]
OAUTH["OAuth 2.0 Bearer Token
NRF = 授权服务器
细粒度服务操作授权
令牌签名+有效期+受众校验"]
end
subgraph L2["传输层安全 (Transport Security)"]
MTLS["TLS 1.2/1.3 / mTLS
NF间双向证书认证
HTTP/2加密与完整性保护
防窃听/篡改/伪造"]
end
subgraph L1["网络域安全 (Network Domain Security)"]
NDS["NDS/IP (TS 33.310/33.210)
IPsec/za接口
安全网关SEG隔离
参考点接口与边界保护"]
end
UE((UE)) --> RAN((gNB))
RAN -->|N2/N3| AMF1[AMF]
AMF1 -.->|SBI HTTP/2| SMF1[SMF]
AMF1 --> OAUTH
AMF1 --> MTLS
RAN --> NDS
style OAUTH fill:#e8f5e9,stroke:#2e7d32
style MTLS fill:#fff3e0,stroke:#ef6c00
style NDS fill:#e3f2fd,stroke:#1565c0
```
**设计意图（Why three layers?）**：
| 防护层 | 解决的核心威胁 | 3GPP依据 |
|--------|---------------|---------|
| NDS/IP (L1) | 外部网络/不可信域对核心网的窃听与注入 | TS 33.310 §6.1, TS 33.501 Clause 13 |
| TLS/mTLS (L2) | NF节点身份伪造、传输层窃听篡改 | TS 33.501 Clause 13.3, TS 29.500 §6 |
| OAuth2 (L3) | 合法NF越权调用未授权的服务操作、令牌重放 | TS 33.501 Clause 13.2, TS 29.510 §5.4 |
注意：**L1与L2/3并非必然叠加**。在运营商内部"可信域（trusted domain）"中，SBI可仅依赖mTLS（L2）+OAuth2（L3），而NDS/IP（L1）主要保护跨安全域的参考点接口（如N2、N4、N9）或漫游SEPP对接。Release 16起，3GPP明确将OAuth2从"必选"调整为**运营商可选项**——若已部署mTLS双向认证，OAuth2可作为增强而非强制。
## 三、NRF充当OAuth 2.0授权服务器：核心机制
### 3.1 OAuth 2.0 Client Credentials授权模式
5GC中的NF均为**机密客户端（confidential client）**，没有用户参与，因此3GPP采用OAuth 2.0的**客户端凭证模式（Client Credentials Grant，RFC 6749 §4.4）**：
- **资源拥有者（Resource Owner）**：NF Service Producer（如UDM），它拥有自己提供的服务资源。
- **客户端（Client）**：NF Service Consumer（如AMF），它希望调用Producer的服务。
- **授权服务器（Authorization Server）**：**NRF**，负责签发访问令牌。
- **资源服务器（Resource Server）**：同样是NF Service Producer。
NRF在SBI中扮演"双重角色"：它既是服务注册中心（提供 `Nnrf_NFManagement`、`Nnrf_NFDiscovery` 服务），又是OAuth2授权服务器（提供专门的 `Nnrf_AccessToken` 服务，见TS 29.510 §5.4）。
### 3.2 完整信令时序图
下图描述一次典型的"AMF调用UDM的 `nudm-sdm` 服务"过程中，SBI安全四步曲的完整信令流（以mTLS + OAuth2双启用为场景）：
```mermaid
sequenceDiagram
autonumber
participant C as NF Consumer (AMF)
participant N as NRF (授权服务器)
participant P as NF Producer (UDM)
Note over C,N: 阶段0: 前置 - mTLS已建立 (运营商CA签发证书)
Note over C,P: 所有HTTP/2连接均通过mTLS双向认证
rect rgb(232,245,233)
Note over C,N: 阶段1: NF注册 (Nnrf_NFManagement_NFRegister)
C->>N: PUT /nf-instances/{amfInstId}
NFProfile{nfType=AMF, services:[...],
oauth2Required=true}
N->>N: 校验AMF证书有效性 (mTLS)
生成/存储NFProfile
N-->>C: 201 Created + NFProfile
(含NRF的OAuth2能力指示customInfo)
end
rect rgb(227,242,253)
Note over C,N: 阶段2: 服务发现 (Nnrf_NFDiscovery_Request)
C->>N: GET /nf-instances?
target-nf-type=UDM&
service-names=nudm-sdm&
requester-nf-type=AMF
N-->>C: 200 OK + DiscoveryResult
(UDM实例URI列表)
end
rect rgb(255,243,224)
Note over C,N: 阶段3: 申请访问令牌 (Nnrf_AccessToken_Obtain)
C->>N: POST /oauth2/token
grant_type=client_credentials
nfInstanceId={amfInstId}
targetNfType=UDM
scope=nudm-sdm
N->>N: 验证消费者身份(mTLS)
验证scope授权矩阵
用NRF私钥签发JWT
N-->>C: 200 OK {access_token=JWT,
token_type=Bearer,
expires_in=3600, scope=nudm-sdm}
end
rect rgb(252,228,236)
Note over C,P: 阶段4: 携带令牌调用服务
C->>P: GET /nudm-sdm/v2/{supi}/am-data
Authorization: Bearer {JWT}
(经mTLS传输)
P->>P: 用NRF公钥验签JWT
校验exp/aud/sub/scope
校验自身=aud目标
P-->>C: 200 OK + SessionManagementSubscriptionData
end
```
逐消息解析关键信息元素（IE）：
**阶段1（注册）**——`NFProfile`（TS 29.510 §6.2.6）核心字段：
- `nfInstanceId`（UUID）：NF实例唯一标识，后续作为JWT的 `sub`/`client_id` 基础。
- `nfType`：枚举（AMF/SMF/UDM/...），授权矩阵以此匹配。
- `nfServices[]`：该NF提供的服务列表，含 `serviceName`、`versions`、`uri`、`allowedNfTypes`。
- `oauth2Required`（或经 `customInfo` 携带）：指示该NF是否要求调用方携带OAuth2令牌。
**阶段3（申请令牌）**——`Nnrf_AccessToken_Obtain`（TS 29.510 §5.4.2.2）：
- `grant_type=client_credentials`：固定值，标识客户端凭证模式。
- `nfInstanceId`：消费者自身实例ID。
- `targetNfType`：目标生产者类型（用于设置JWT的 `aud`）。
- `scope`：请求的服务范围，3GPP定义的scope字符串形如 `nudm-sdm`、`nausf-auth`（即服务名小写连字符）。
## 四、Access Token（JWT）结构深度拆解
3GPP规定访问令牌采用 **JWT（JSON Web Token，RFC 7519）** 格式，由NRF用其私钥签名（通常RS256）。这是整个机制中信息密度最高、最容易出故障的部分。
### 4.1 JWT三段式结构与Claim详解
```mermaid
flowchart TD
subgraph Header["Header (JOSE)"]
H["alg=RS256
typ=JWT
x5c=NRF证书链"]
end
subgraph Payload["Payload (Claims集)"]
P1["iss: NRF FQDN"]
P2["sub: 消费者NF实例ID"]
P3["aud: 生产者NF类型/实例"]
P4["scope: nudm-sdm"]
P5["exp/iat/nbf: 时间戳"]
P6["jti: 令牌唯一ID"]
P7["client_id: 消费者标识"]
end
subgraph Sig["Signature"]
S["RSA-SHA256(NRF私钥)
对 base64(header).base64(payload) 签名"]
end
Header --> Enc1[Base64URL]
Payload --> Enc2[Base64URL]
Sig --> Enc3[Base64URL]
Enc1 --> DOT((.))
Enc2 --> DOT
Enc3 --> DOT
DOT --> JWT["JWT 字符串"]
style P1 fill:#fff3e0
style P3 fill:#fff3e0
style P4 fill:#e8f5e9
style S fill:#ffebee
```
### 4.2 JWT Claim参数说明表
| Claim | 含义 | 示例值 | 作用与校验要点 |
|-------|------|--------|---------------|
| `iss` | 签发者（Issuer） | `https://nrf.operator.com` | Producer必须校验签发者是否为可信NRF（与本地预置NRF证书/URI比对）|
| `sub` | 主体（Subject） | `AMF实例UUID` | 标识令牌持有人=发起调用的消费者，用于审计与授权追溯 |
| `aud` | 受众（Audience） | `UDM` 或具体实例ID | **Producer必须确认自己是 `aud` 目标**，防止令牌被转用到非目标NF |
| `scope` | 授权范围 | `nudm-sdm` | Producer校验请求的服务是否落在scope内，越权调用直接拒绝 |
| `exp` | 过期时间（Unix时间戳） | `1735516800` | Producer校验当前时间 NRF使用其**私钥**签发令牌；所有NF Producer只需持有**NRF的公钥（从NRF证书 `nrf.pem` 提取）**即可验签。
这一设计避免了"NRF需为每个NF维护公钥、NF之间需互信证书"的N²扩展性问题——NRF是唯一的信任锚点（Trust Anchor），这与PKI中"根CA签名、终端用根CA公钥验签"的模型完全一致。
## 五、mTLS双向认证：传输层的"身份证"
OAuth2只解决了**应用层授权**（"你能调用什么服务"），却不解决**传输层身份**（"你是谁"）。如果仅有OAuth2而没有mTLS，攻击者可能窃取令牌后在任意网络位置重放（Bearer令牌的固有弱点）。因此TS 33.501 Clause 13.3要求NF间SBI在传输层使用TLS，并强烈建议mTLS：
```mermaid
sequenceDiagram
autonumber
participant C as NF Consumer (AMF)
participant P as NF Producer (UDM)
C->>P: ClientHello + supported cipher suites
P->>C: ServerHello + 服务器证书 (UDM证书)
C->>P: Certificate Request
Note over C: AMF用本地CA公钥
校验UDM证书有效性
C->>P: 客户端证书 (AMF证书) + 密钥交换
Note over P: UDM用本地CA公钥
校验AMF证书有效性
Note over C,P: 协商出对称主密钥 (TLS 1.3 1-RTT)
C->>P: HTTP/2 + Bearer JWT (全程加密通道)
P-->>C: 加密响应
```
**证书体系**遵循TS 33.310（NDS/IP认证框架）与TS 33.501 Clause 13.4：
- 证书由**运营商内部CA（或运营商级PKI）**签发，证书Subject/SubjectAltName包含NF的FQDN与nfInstanceId。
- 证书校验内容包括：CA信任链、有效期、吊销状态（CRL/OCSP）、SAN匹配。
- mTLS握手成功 = 双方完成"节点级身份认证"，此后HTTP/2连接即受加密与完整性保护。
## 六、Token验证流程：Producer侧的关键逻辑
当UDM收到一个携带Bearer JWT的 `nudm-sdm` 请求时，必须执行完整的验证流水线（TS 33.501 Clause 13.3 + RFC 7519）。这是故障多发点，也是抓包排错的核心：
```mermaid
flowchart TD
R[收到请求: Authorization: Bearer JWT] --> A1{令牌是否存在?}
A1 -->|否| R401[401 Unauthorized: 缺少令牌]
A1 -->|是| A2[解析JWT三段式结构]
A2 --> A3{Header.alg == RS256
且 alg!=none?}
A3 -->|否| R401b[401: 算法非法]
A3 -->|是| A4[用NRF公钥验签
从nrf.pem提取]
A4 --> A5{签名有效?}
A5 -->|否| R401c[401: 签名失败]
A5 -->|是| A6{exp未过期
且 nbf已生效?}
A6 -->|否| R401d[401: 令牌过期]
A6 -->|是| A7{aud 包含自身UDM实例
或UDM类型?}
A7 -->|否| R403a[403: 受众不匹配]
A7 -->|是| A8{scope 覆盖
请求的服务 nudm-sdm?}
A8 -->|否| R403b[403: scope越权]
A8 -->|是| A9[jti是否在黑名单?]
A9 -->|是| R403c[403: 令牌已吊销]
A9 -->|否| OK[✅ 验证通过,处理业务]
style OK fill:#c8e6c9
style R401 fill:#ffcdd2
style R403 fill:#ffe0b2
```
**设计意图**：这套流水线实现了**纵深校验**——任何一环失败即拒绝，攻击者必须同时拥有有效证书（mTLS）、有效签名令牌（NRF私钥未泄露）、未过期、受众匹配、scope匹配，才能成功调用。其中 `aud` 校验尤为重要：它防止AMF为调用UDM而申请的令牌被转用于攻击PCF，实现了"令牌绑定到特定生产者"。
## 七、mTLS vs OAuth2 vs NDS/IP：三种方案对比
| 维度 | NDS/IP (IPsec) | mTLS | OAuth2 JWT |
|------|---------------|------|-----------|
| **防护层** | 网络域 (L3) | 传输层 (L4-L7) | 应用层 (L7) |
| **认证对象** | 安全网关SEG/节点 | NF节点（双向证书） | NF实例+服务操作 |
| **授权粒度** | 网元/IP级 | 网元级 | **服务操作级（最细）** |
| **状态维护** | SA有状态 | TLS会话有状态 | 无状态（签名自包含）|
| **动态发现适配** | 差（需预配置SA） | 中（证书可动态） | **好（令牌即取即用）** |
| **典型3GPP依据** | TS 33.310/33.210 | TS 33.501 §13.3 | TS 33.501 §13.2, TS 29.510 §5.4 |
| **可选项** | 是（运营商域内可省）| 推荐必选 | R16起可选 |
| **扩展性** | N²（双节点SA） | N²（证书信任） | **N**（仅NRF为中心）|
| **抗重放** | 靠IPsec序列号 | 靠TLS序列号 | 靠exp+jti+aud |
**结论**：mTLS与OAuth2并非冗余而是**互补**——mTLS保证"连接可信"，OAuth2保证"调用授权"，二者叠加才能覆盖SBI的动态、细粒度需求。这也是3GPP虽在R16将OAuth2设为可选，但主流厂商（华为、爱立信、中兴、Cisco）在2024年后产品中均默认双启用的根本原因。
## 八、抓包识别与故障排查实战
### 8.1 抓包如何识别SBI安全流程
在NF与NRF/NF之间部署抓包（通常为HTTPS代理如mitmproxy，因SBI全程TLS加密，无法直接tcpdump看到明文），可观察到以下典型特征：
1. **NF注册**：`PUT /nnrf-nfm/v1/nf-instances/{id}`，Body含完整 `NFProfile` JSON。
2. **令牌申请**：`POST /oauth2/token`，Content-Type为 `application/x-www-form-urlencoded`，返回体含 `access_token`（很长的JWT字符串，三段用`.`分隔）。
3. **服务调用**：HTTP/2请求头出现 `Authorization: Bearer eyJhbGciOi...`，其中 `eyJ` 是 `{"` 的Base64，是识别JWT的快速特征。
### 8.2 常见故障点与排错思路
| 故障现象 | HTTP响应 | 可能原因 | 排查建议 |
|---------|---------|---------|---------|
| 令牌缺失 | 401 Unauthorized | Consumer未启用OAuth2 / 未先申请令牌 | 检查NRF返回的NFProfile中oauth2指示 |
| 签名失败 | 401 invalid_token | Producer持有的NRF证书过期/不匹配 | 比对Producer `nrf.pem` 与NRF实际证书 |
| 令牌过期 | 401 invalid_token | Consumer本地时钟漂移 / 未及时刷新 | 检查NTP，确认 `exp` 与本地时间偏差 |
| 受众不匹配 | 403 insufficient_scope/aud | 申请令牌时 `targetNfType` 错误 | 确认令牌申请参数与实际调用目标一致 |
| mTLS握手失败 | TLS alert | 证书未由可信CA签发/SAN不匹配 | 检查CA证书链部署、FQDN配置 |
| scope越权 | 403 | 申请scope未覆盖目标服务 | 检查NRF授权矩阵配置 |
## 九、常见问题
**Q1: 既然mTLS已经实现双向认证，OAuth2令牌是不是多余？**
A: 不多余。mTLS只解决"节点身份认证"（证明是合法的AMF），而OAuth2解决"服务操作授权"（证明AMF有权调用UDM的 `nudm-sdm` 而非 `nudm-uecm`）。二者防护层不同：mTLS在传输层，OAuth2在应用层。更重要的是，OAuth2令牌携带 `scope`、`aud`、`exp`，可实现细粒度授权与时效控制，这是mTLS做不到的。但在运营商内部可信域中，若授权需求简单，可仅用mTLS以降低信令开销（R16起允许）。
**Q2: JWT令牌有效期通常多长？过期后如何刷新？**
A: 3GPP未强制规定，典型值为3600秒（1小时）。Consumer应在令牌即将过期（如剩余<10%）时主动重新向NRF申请，而非等到401再处理（会打断业务流）。多数实现采用"令牌缓存池"机制，按 (targetNfType, scope) 维度缓存复用，减少对NRF的信令压力。
**Q3: NRF如果宕机，SBI调用会全部失败吗？**
A: 短期内不会立即失败。已签发的OAuth2令牌在有效期内仍可被Producer独立验签（JWT无状态、自包含），Producer无需在线联系NRF。但新令牌申请与NF发现将中断。这也是为何NRF通常部署为高可用集群（主备或负载分担），是5GC可用性的关键节点。
**Q4: Nnrf_AccessToken服务与Nnrf_NFDiscovery是同一个服务吗？**
A: 不是。TS 29.510定义NRF提供多个独立服务：`Nnrf_NFManagement`（注册管理）、`Nnrf_NFDiscovery`（服务发现）、`Nnrf_AccessToken`（OAuth2令牌签发）。它们是SBI服务化拆分的体现，各有独立API路径（`/nf-instances`、`/oauth2/token` 等）。
**Q5: 令牌的 `scope` 字段格式是什么？**
A: scope使用3GPP定义的服务名，通常为小写连字符形式，如 `nudm-sdm`、`nausf-auth`、`namf-comm`。它对应TS 29.5xx系列定义的具体SBI服务。一次申请可包含多个scope（空格分隔）。Producer据此判断请求的具体服务操作是否被授权。
## 参考来源
1. [3GPP TS 33.501 V19.x.x — Security architecture and procedures for the 5G system](https://www.3gpp.org/dynareport/33501.htm) — Clause 13 (Security of Service-Based Interface), Clause 13.2/13.3/13.4
2. [3GPP TS 29.510 — Network Repository Function (NRF)](https://www.3gpp.org/dynareport/29510.htm) — §5.4 Nnrf_AccessToken Service, §5.4.2.2 Access Token Request/Response, §6.2.6 NFProfile
3. [3GPP TS 29.500 — 5G System; Technical Realization of Service Based Architecture](https://www.3gpp.org/dynareport/29500.htm) — §6 Security aspects of SBI, OAuth2 token flow
4. [free5GC OAuth2 Design — 开源参考实现密钥管理策略](https://free5gc.org/doc/OAuth2/OAuth2Design/) — NRF私钥签发/NF公钥验签设计
5. [free5GC Blog: Authentication Mechanism in NRF - What Is OAuth?](https://free5gc.org/blog/20230802/20230802/) — Nnrf_AccessToken服务流程图（源自TS 29.510 Figure 5.4.2.2-1）
6. [OAuth 2.0 Authorization in 5G Core Networks: Architecture, Workflows and Security Challenges](https://www.lfdecentralizedtrust.org/blog/oauth-2.0-authorization-in-5g-core-networks-architecture-workflows-and-security-challenges) — 5GC OAuth2架构与安全挑战分析
---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
