# 5G SBA的OAuth2令牌授权机制全链拆解 ## 一、为什么5GC核心网要引入OAuth 2.0 4G EPC的核心网网元之间是点对点（P2P）的Diameter/GTP-C接口，安全靠静态配置的IPsec隧道（NDS/IP，TS 33.210）。这套机制在云原生、微服务化的5GC里彻底失效了——5G核心网采用**服务化架构（SBA, Service-Based Architecture）**，所有网络功能（NF）通过HTTP/2 RESTful API互相调用，NF实例还会随负载动态扩缩容，靠手工预共享密钥根本管不过来。 3GPP在TS 33.501第13章给出了答案：**用OAuth 2.0的"客户端凭证许可（Client Credentials Grant）"做服务级授权，NRF（网络仓储功能）充当授权服务器（Authorization Server）**。每个NF调用别的NF服务前，先向NRF申请一个带签名的JWT令牌，调用时在HTTP头里带上`Authorization: Bearer `，生产方NF验证令牌签名和权限后才放行。 这是一个把"动态服务发现 + 去中心化授权 + 短时令牌"三者结合的精巧设计，也是5GC从"管道"走向"云原生API网关"的标志性安全机制。 ## 二、规范定位与三层安全模型 SBA安全由三个相对独立的层叠加构成，必须分清它们各自的职责： | 安全层 | 规范条款 | 机制 | 解决的问题 | |--------|---------|------|-----------| | 传输层（Transport） | TS 33.501 §13.1 | TLS 1.2/1.3 或 NDS/IP | NF间双向认证（mTLS）、链路机密性与完整性 | | 消息层（Message） | TS 33.501 §13.2 | 对敏感属性单独完整性保护 | 防止中间节点篡改关键IE（如SUPI、DNN） | | 授权层（Authorization） | TS 33.501 §13.3 / TS 29.510 §5.4 | OAuth 2.0 + JWT | 服务级访问控制：谁（哪个NF）能调谁的哪个服务 | 关键设计意图：**把认证和授权解耦**。mTLS在传输握手时一次性完成"我是谁"，OAuth令牌则在每次服务调用时回答"我能做什么"。授权完全动态——生产方NF不需要预先知道每个消费方，它只信任NRF签发的令牌，这让NF实例的弹性伸缩成为可能。 ## 三、Nnrf_AccessToken 完整信令时序 整个流程围绕NRF暴露的**`/oauth2/token`端点（Token Endpoint）**展开，对应TS 29.510 §5.4.2 定义的`Nnrf_AccessToken`服务。 ```mermaid sequenceDiagram autonumber participant C as NF消费方
(Consumer, 如AMF) participant N as NRF
(授权服务器) participant P as NF生产方
(Producer, 如AUSF) Note over C,N: 前置：C/N/P 两两已建立 mTLS（基于运营商CA证书） C->>N: POST /oauth2/token
grant_type=client_credentials
nfType=AMF, targetNfType=AUSF
scope=nausf-ueauthentication
nfInstanceId= N->>N: 1. 通过mTLS验证C身份
2. 查NFProfile确认C对P的scope是否被授权 N-->>C: 200 OK
access_token=
token_type=Bearer
expires_in=3600 Note over C: 按targetNfType+scope缓存Token
直至exp（无refresh_token） C->>P: HTTP/2 服务调用
Authorization: Bearer P->>P: 用NRF公钥验签
校验 exp / aud / scope alt 校验通过 P-->>C: 200 OK 服务响应 else 令牌过期/无效 P-->>C: 401 + WWW-Authenticate: Bearer error="invalid_token" Note over C: 删除缓存,重新向NRF申请 end ``` 需要强调一个RFC 6749的硬性约束：**Client Credentials许可本身不签发refresh_token**。令牌过期后消费方必须用`grant_type=client_credentials`重新申请，这是OAuth 2.0规范决定的，不是3GPP的额外限制。这也是为什么消费方要本地缓存令牌并跟踪`expires_in`——否则每次服务调用都打一次NRF，NRF会成为瓶颈。 ## 四、Access Token Request 的IE拆解 请求体是标准的`application/x-www-form-urlencoded`表单，TS 29.510 §5.4.2.2 逐字段定义： | 参数 | 必选 | 取值/含义 | |------|------|----------| | `grant_type` | 是 | 固定为 `client_credentials` | | `nfInstanceId` | 是 | 消费方NF实例标识（UUID） | | `nfType` | 是 | 消费方NF类型，如 `AMF`/`SMF`/`PCF` | | `targetNfType` | 是 | 目标生产方NF类型 | | `scope` | 是 | 申请的服务名，空格分隔，如 `nausf-ueauthentication` | | `targetNfInstanceId` | 否 | 指定目标实例ID（精准定位） | | `targetPlmn` | 否 | 目标PLMN（漫游场景） | | `requestPlmn` | 否 | 请求方PLMN | | `targetNfSetId` | 否 | 目标NF集合（负载均衡组） | `scope`是这个机制的核心——它直接对应一个**服务化API名**，比如AUSF的鉴权服务`nausf-ueauthentication`、UDM的签约数据`nudm-sdm`、SMF的会话管理`nsmf-pdusession`。NRF就是根据"`nfType + targetNfType + scope`"三元组，查自己存储的NFProfile中的授权关系，决定是否签发令牌。 NRF成功响应返回JSON： ```json { "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiO...", "token_type": "Bearer", "expires_in": 3600 } ``` 失败则返回400，带RFC 6749标准错误码：`invalid_client`（身份认证失败）、`invalid_scope`（scope未授权）、`unauthorized_client`（该NF类型无权申请此scope）。 ## 五、JWT令牌结构深度拆解 `access_token`本质上是一个**RFC 7519规范的JWT（JSON Web Token）**，由三段Base64URL编码以`.`连接：`Header.Payload.Signature`。 ```mermaid flowchart TB JWT["JWT = Header.Payload.Signature"] JWT --> H["Header（头部）
alg: RS256 / ES256
typ: JWT"] JWT --> PL["Payload（声明 Claims）
iss / sub / aud
exp / iat / scope
nfType / targetNfType
targetPlmn / jti"] JWT --> S["Signature（签名）
RS256(NRF私钥,
Base64URL(Header).'.'.
Base64URL(Payload))"] S -.->|验证| V["生产方用NRF公钥验签"] ``` JWT的关键Claims（TS 29.510 Annex / TS 33.501 §13）： | Claim | 含义 | 在授权中的作用 | |-------|------|--------------| | `iss` | 签发者，NRF的FQDN | 生产方据此定位验证公钥 | | `sub` | 消费方`nfInstanceId` | 标识"谁要调用"，等于`client_id` | | `aud` | 受众，`targetNfType`+`targetPlmn` | **防止令牌被转用到非目标NF** | | `exp` | 过期时间戳 | 令牌生命周期（默认~1小时） | | `iat` | 签发时间戳 | 防重放辅助 | | `scope` | 授权的服务范围 | 生产方据此判定能否调该服务 | | `nfType` / `targetNfType` | NF类型对 | 二次校验调用关系 | | `jti` | 令牌唯一ID | 可用于吊销/审计 | 签名算法为**RS256（RSASSA-PKCS1-v1_5 + SHA-256）**或ES256，由NRF的私钥完成。这带来一个重要推论：**NRF是整个PLMN信任锚**——谁掌握NRF私钥，谁就能伪造任意NF的调用凭证。商用部署中NRF私钥通常由HSM（硬件安全模块）保护。 ## 六、生产方验证状态流与错误处理 生产方NF收到带Bearer令牌的请求后，执行一套严格的验证逻辑： ```mermaid stateDiagram-v2 [*] --> 收到Bearer令牌 收到Bearer令牌 --> 验签: 取NRF公钥(按iss) 验签 --> 校验exp: 签名有效 验签 --> R401: 签名无效 校验exp --> 校验aud: 未过期 校验exp --> R401: 已过期 校验aud --> 校验scope: 受众匹配本NF 校验aud --> R403: 受众不符 校验scope --> 放行: 权限匹配 校验scope --> R403: 权限不足 放行 --> [*]: 返回服务响应 R401 --> [*]: 401 invalid_token
消费方重新申请 R403 --> [*]: 403 insufficient_scope ``` 生产方验证用的**NRF公钥**从哪来？通过NRF的NFProfile携带——NRF在自身注册信息中分发其签名证书（或运营商统一CA签发的证书），各NF通过`Nnrf_NFManagement_NFStatusSubscribe`订阅并缓存该公钥。证书轮换时需要订阅通知机制联动，否则会出现大规模验签失败。 ## 七、设计意图的深层逻辑 回到三个"为什么"： 1. **为什么是OAuth 2.0而不是延续IPsec？** SBA是REST over HTTP/2，NF实例动态增删。IPsec是点对点静态隧道，新增NF就要配对端密钥，运维成本O(N²)。OAuth令牌让生产方"只信令牌不信人"，授权关系集中在NRF，扩展性变为O(N)。 2. **为什么令牌要短时（expires_in）？** 令牌是Bearer类型——谁拿到谁能用，没有加密保护载荷之外的凭据绑定。短生命周期把令牌泄露的爆炸半径限制在数小时内。配合mTLS传输层加密，令牌即使在网络中流转也被TLS保护。 3. **为什么用`aud`绑定targetNfType？** 防止"横向越权"：一个为调AUSF申请的令牌不能被拿去调UDM。`aud`+`scope`双重约束把令牌的可用面收窄到"指定NF的指定服务"。 ## 八、抓包识别与实战排错 ### 抓包识别 在NF间（Nrf/Nxxxb接口）抓HTTPS流量时（需解密TLS），OAuth流程的特征非常明显： - **令牌申请**：`POST /oauth2/token`，Content-Type为`application/x-www-form-urlencoded`，body含`grant_type=client_credentials`。 - **令牌使用**：后续服务调用请求头出现`Authorization: Bearer eyJ...`，其中`eyJ`是`{"`的Base64URL编码（JWT标志）。 - 解码JWT：把Payload段Base64URL解码即可看到`iss/sub/aud/exp/scope`，无需密钥。 ### 常见故障点 | 故障现象 | 根因 | 排错思路 | |---------|------|---------| | 服务调用返回401 `invalid_token` | 令牌过期或验签失败 | 检查`exp`与系统时间偏差；确认NRF公钥已分发且未轮换 | | 服务调用返回403 `insufficient_scope` | 申请的scope不匹配 | 核对消费方NFProfile授权的scope列表 | | 大规模验签失败 | NRF证书轮换未通知 | 检查`Nnrf_NFManagement`订阅是否生效 | | 令牌申请返回400 `unauthorized_client` | nfType与targetNfType授权关系缺失 | 在NRF检查NFProfile的allowed service | ## 九、与其它授权方案的对比 | 维度 | SBA OAuth2 + JWT | 纯mTLS授权 | 4G NDS/IPsec | |------|------------------|-----------|--------------| | 授权粒度 | 服务级（scope） | 实例级（连上即可） | 网元级（隧道） | | 动态性 | 高（令牌随申请） | 低（证书固定） | 极低（静态隧道） | | 扩展性 | O(N)，集中NRF | O(N²) | O(N²) | | 漫游支持 | `targetPlmn` claim天然支持 | 需跨域证书互信 | 需SEG网关 | | 适用场景 | 云原生SBI | 简单/测试 | 传统P2P接口 | ## 常见问题 **Q1：OAuth2的令牌和mTLS是什么关系，能否只用其中一个？** A：两者职责不同。mTLS解决"传输层身份认证与加密"，OAuth令牌解决"应用层服务授权"。理论上可以只开mTLS（free5GC默认即如此），但这意味着"连上TLS就能调任意服务"，缺乏服务级访问控制。商用部署强制两者叠加，mTLS做认证、令牌做授权，纵深防御。 **Q2：令牌过期了，消费方怎么知道要重新申请？** A：靠生产方返回的401 + `WWW-Authenticate: Bearer error="invalid_token"`触发。因为Client Credentials许可不发refresh_token，消费方只能删缓存后重新调`/oauth2/token`。因此消费方必须本地跟踪`expires_in`提前刷新，避免每次都撞401。 **Q3：JWT载荷是明文Base64编码，会不会泄露信息？** A：JWT设计上不提供机密性，Payload任何人都可解码。5GC靠**传输层TLS加密**保护令牌在传输中不被窃听。载荷里也不放高敏数据（不放长期密钥），最敏感的也就是SUPI等业务标识，且受mTLS保护。需要机密性应靠TLS，而非指望JWT加密。 **Q4：漫游场景下，归属地和拜访地的NRF令牌如何协作？** A：通过`targetPlmn`/`requestPlmn` claim区分。vNRF（拜访地）发现目标在hPLMN时，可为消费方签发带`targetPlmn=hPLMN`的令牌；hPLMN的生产方验证`aud`中的PLMN是否匹配自己。跨域时还涉及SEPP（N32）对SBI流量的保护，令牌与SEPP是正交的两层安全。 **Q5：NRF是单点信任锚，它挂了或私钥泄露怎么办？** A：这是架构级风险。私钥泄露=可伪造任意NF凭证，必须HSM保护+严格审计。NRF高可用靠多实例+共享密钥材料（或KMS统一托管）；令牌短时性也限制了泄露窗口。Rel-18/19在研究分布式授权与去中心化令牌签发（如基于区块链的OAuth增强），试图降低单点信任依赖。 ## 参考来源 1. [3GPP TS 33.501 V19.x — Security architecture and procedures for 5G system](https://www.3gpp.org/dynareport/33501.htm) — §13 Security of the service based architecture, §13.3 Authorization 2. [3GPP TS 29.510 V19.x — 5G System; Network function repository services; Stage 3](https://www.3gpp.org/dynareport/29510.htm) — §5.4 Nnrf_AccessToken service, §5.4.2.2 Access Token Request 3. [Ericsson — Security for 5G Service-Based Architecture](https://www.ericsson.com/en/blog/2020/8/security-for-5g-service-based-architecture) — Token-based authorization with OAuth 2.0 in SBA 4. [Ericsson — Security for 5G SBA: updates since Release 16](https://www.ericsson.com/en/blog/2024/2/5g-sba-security-release-16-updates) — TS 33.501 Rel-16 assertion更新 5. [free5GC — Authentication Mechanism in NRF: What Is OAuth?](https://free5gc.org/blog/20230802/20230802/) — Nnrf_AccessToken服务实现与流程图 6. [IETF RFC 6749 — OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) — Client Credentials Grant（§4.4） 7. [IETF RFC 7519 — JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519) — JWT结构与Claims定义 --- > 本文由「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 等场景全覆盖。