首页 › security › 5G SBA的OAuth2令牌授权机制拆解

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 <token>，生产方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服务。

sequenceDiagram
    autonumber
    participant C as NF消费方<br/>(Consumer, 如AMF)
    participant N as NRF<br/>(授权服务器)
    participant P as NF生产方<br/>(Producer, 如AUSF)

    Note over C,N: 前置：C/N/P 两两已建立 mTLS（基于运营商CA证书）

    C->>N: POST /oauth2/token<br/>grant_type=client_credentials<br/>nfType=AMF, targetNfType=AUSF<br/>scope=nausf-ueauthentication<br/>nfInstanceId=<C的实例ID>
    N->>N: 1. 通过mTLS验证C身份<br/>2. 查NFProfile确认C对P的scope是否被授权
    N-->>C: 200 OK<br/>access_token=<JWT><br/>token_type=Bearer<br/>expires_in=3600
    Note over C: 按targetNfType+scope缓存Token<br/>直至exp（无refresh_token）
    C->>P: HTTP/2 服务调用<br/>Authorization: Bearer <JWT>
    P->>P: 用NRF公钥验签<br/>校验 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：

{
  "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。

flowchart TB
    JWT["JWT = Header.Payload.Signature"]
    JWT --> H["Header（头部）<br/>alg: RS256 / ES256<br/>typ: JWT"]
    JWT --> PL["Payload（声明 Claims）<br/>iss / sub / aud<br/>exp / iat / scope<br/>nfType / targetNfType<br/>targetPlmn / jti"]
    JWT --> S["Signature（签名）<br/>RS256(NRF私钥,<br/>Base64URL(Header).'.'.<br/>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令牌的请求后，执行一套严格的验证逻辑：

stateDiagram-v2
    [*] --> 收到Bearer令牌
    收到Bearer令牌 --> 验签: 取NRF公钥(按iss)
    验签 --> 校验exp: 签名有效
    验签 --> R401: 签名无效
    校验exp --> 校验aud: 未过期
    校验exp --> R401: 已过期
    校验aud --> 校验scope: 受众匹配本NF
    校验aud --> R403: 受众不符
    校验scope --> 放行: 权限匹配
    校验scope --> R403: 权限不足
    放行 --> [*]: 返回服务响应
    R401 --> [*]: 401 invalid_token<br/>消费方重新申请
    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流程的特征非常明显：

常见故障点

故障现象 根因 排错思路
服务调用返回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 — §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 — §5.4 Nnrf_AccessToken service, §5.4.2.2 Access Token Request
  3. Ericsson — 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 — TS 33.501 Rel-16 assertion更新
  5. free5GC — Authentication Mechanism in NRF: What Is OAuth? — Nnrf_AccessToken服务实现与流程图
  6. IETF RFC 6749 — OAuth 2.0 Authorization Framework — Client Credentials Grant（§4.4）
  7. IETF RFC 7519 — JSON Web Token (JWT) — 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 等场景全覆盖。

51学通信知识星球海报-扫码加入

📎 本分类最新文章