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安全划分为三个相互独立的防护层，分别对应不同的威胁模型：

flowchart TB
    subgraph L3["应用层安全 (Application Security)"]
        OAUTH["OAuth 2.0 Bearer Token<br/>NRF = 授权服务器<br/>细粒度服务操作授权<br/>令牌签名+有效期+受众校验"]
    end
    subgraph L2["传输层安全 (Transport Security)"]
        MTLS["TLS 1.2/1.3 / mTLS<br/>NF间双向证书认证<br/>HTTP/2加密与完整性保护<br/>防窃听/篡改/伪造"]
    end
    subgraph L1["网络域安全 (Network Domain Security)"]
        NDS["NDS/IP (TS 33.310/33.210)<br/>IPsec/za接口<br/>安全网关SEG隔离<br/>参考点接口与边界保护"]
    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?）：

注意：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双启用为场景）：

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}<br/>NFProfile{nfType=AMF, services:[...],<br/>oauth2Required=true}
    N->>N: 校验AMF证书有效性 (mTLS)<br/>生成/存储NFProfile
    N-->>C: 201 Created + NFProfile<br/>(含NRF的OAuth2能力指示customInfo)
    end

    rect rgb(227,242,253)
    Note over C,N: 阶段2: 服务发现 (Nnrf_NFDiscovery_Request)
    C->>N: GET /nf-instances?<br/>target-nf-type=UDM&<br/>service-names=nudm-sdm&<br/>requester-nf-type=AMF
    N-->>C: 200 OK + DiscoveryResult<br/>(UDM实例URI列表)
    end

    rect rgb(255,243,224)
    Note over C,N: 阶段3: 申请访问令牌 (Nnrf_AccessToken_Obtain)
    C->>N: POST /oauth2/token<br/>grant_type=client_credentials<br/>nfInstanceId={amfInstId}<br/>targetNfType=UDM<br/>scope=nudm-sdm
    N->>N: 验证消费者身份(mTLS)<br/>验证scope授权矩阵<br/>用NRF私钥签发JWT
    N-->>C: 200 OK {access_token=JWT,<br/>token_type=Bearer,<br/>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<br/>Authorization: Bearer {JWT}<br/>(经mTLS传输)
    P->>P: 用NRF公钥验签JWT<br/>校验exp/aud/sub/scope<br/>校验自身=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详解

flowchart TD
    subgraph Header["Header (JOSE)"]
        H["alg=RS256<br/>typ=JWT<br/>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私钥)<br/>对 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参数说明表

4.3 密钥管理设计（free5GC实现启示）

free5GC在v3.4.0的OAuth2设计（TS 29.510与TS 33.501的标准实现参考）揭示了一个关键的简化密钥管理策略：

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：

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公钥<br/>校验UDM证书有效性
    C->>P: 客户端证书 (AMF证书) + 密钥交换
    Note over P: UDM用本地CA公钥<br/>校验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）。这是故障多发点，也是抓包排错的核心：

flowchart TD
    R[收到请求: Authorization: Bearer JWT] --> A1{令牌是否存在?}
    A1 -->|否| R401[401 Unauthorized: 缺少令牌]
    A1 -->|是| A2[解析JWT三段式结构]
    A2 --> A3{Header.alg == RS256<br/>且 alg!=none?}
    A3 -->|否| R401b[401: 算法非法]
    A3 -->|是| A4[用NRF公钥验签<br/>从nrf.pem提取]
    A4 --> A5{签名有效?}
    A5 -->|否| R401c[401: 签名失败]
    A5 -->|是| A6{exp未过期<br/>且 nbf已生效?}
    A6 -->|否| R401d[401: 令牌过期]
    A6 -->|是| A7{aud 包含自身UDM实例<br/>或UDM类型?}
    A7 -->|否| R403a[403: 受众不匹配]
    A7 -->|是| A8{scope 覆盖<br/>请求的服务 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：三种方案对比

结论：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 常见故障点与排错思路

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 — Clause 13 (Security of Service-Based Interface), Clause 13.2/13.3/13.4
2. 3GPP TS 29.510 — Network Repository Function (NRF) — §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 — §6 Security aspects of SBI, OAuth2 token flow
4. free5GC OAuth2 Design — 开源参考实现密钥管理策略 — NRF私钥签发/NF公钥验签设计
5. free5GC Blog: Authentication Mechanism in NRF - What Is OAuth? — 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 — 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 等场景全覆盖。