在5G服務導向架構中，AMF可以發現UDM或SMF的SBI端點，但僅完成發現並不代表其有權擷取使用者資料或建立PDU工作階段。服務導向通訊提高了網路功能之間互動的靈活性，同時也暴露了更廣泛的核心網路API。如果NF服務提供者在未進行授權檢查的情況下處理所有可達請求，就無法可靠判斷呼叫方是否合法、是否已註冊，或是否獲授權使用所請求的服務。
5GC採用OAuth 2.0授權模型解決這一問題。NF服務消費者首先向NRF申請存取權杖，隨後在呼叫目標NF服務提供者時提交該權杖。服務提供者只有在驗證權杖及其授權宣告後才執行所請求的操作。在這一模型中，NRF不僅承擔註冊庫和發現功能，還充當受保護SBI存取的授權伺服器。
未受保護的SBI呼叫風險
5G獨立組網採用服務導向架構，AMF、SMF、UDM和AUSF等網路功能透過HTTP/2服務導向介面公開一個或多個服務。服務消費者可透過標準化HTTP API呼叫這些服務，從而減少緊密的點到點依賴，並支援動態建立服務關係。
例如，在UE註冊過程中，AMF可能呼叫UDM的Nudm_SDM服務以取得訂閱資訊；在建立PDU工作階段時，AMF可能呼叫SMF的Nsmf_PDUSession服務以建立工作階段管理上下文。這兩類流程都涉及敏感的使用者資訊或關鍵的核心網路資源。
如果UDM僅因請求到達正確URI就回傳訂閱資料，它無法確認呼叫方是否為獲授權的AMF。同樣，如果SMF在未驗證請求方身分的情況下建立工作階段，就可能接受來自不可信或設定錯誤的網路功能的呼叫。端點可達僅說明通訊在技術上可行，並不能證明身分或授權。
在雲原生部署中，這類風險更加突出。NF執行個體可能隨著維運需求變化而被建立、彈性擴縮、升級、遷移或刪除。服務消費者也可透過NRF發現選擇不同的服務提供者執行個體。因此，靜態位址和固定對等設定不足以控制每一次獨立的服務請求。
5GC將服務發現與服務授權分離。發現回答的是合適服務位於何處，授權決定當前服務消費者是否有權使用該服務。在業務請求被處理之前，服務消費者必須取得與目標服務相關的憑證，服務提供者也必須驗證該憑證。
NRF作為授權伺服器
OAuth 2.0是一種用於應用之間受控存取的通用授權框架，並非行動網路專用。其標準模型定義了三個主要角色：請求存取的用戶端、核發權杖的授權伺服器，以及保護目標資源或服務的資源伺服器。
在5GC SBI安全模型中，這些角色可直接映射到網路功能行為：
| OAuth 2.0角色 | 5GC實體 | 主要職責 |
|---|---|---|
| 用戶端 | NF服務消費者 | 請求存取權杖並發起服務呼叫 |
| 資源伺服器 | NF服務提供者 | 提供SBI服務並驗證提交的權杖 |
| 授權伺服器 | NRF | 評估請求並核發具有指定範圍的存取權杖 |
當AMF需要呼叫UDM服務時，AMF作為NF服務消費者，UDM作為NF服務提供者，NRF則提供授權功能。AMF在呼叫Nudm_SDM之前先取得權杖，UDM隨後檢查該權杖是否有效，以及其宣告是否允許存取所請求的服務。
為支援這一流程，NRF公開Nnrf_AccessToken服務。權杖請求可包含服務消費者身分、所請求服務名稱、目標NF類型、服務消費者NF類型和用戶端識別碼等資訊。NRF評估請求後，會回傳存取權杖以及權杖類型、有效期間等相關資訊。
NRF不執行所請求的業務操作。它定義授權上下文並核發存取憑證。使用者資料擷取、工作階段建立以及其他特定服務操作仍由相應的NF服務提供者負責。
基於權杖的服務存取流程
5GC定義的NF服務存取流程可分為兩個階段。服務消費者首先從NRF取得存取權杖，然後在請求實際服務時向目標服務提供者提交該權杖。這種分離可阻止未經驗證的請求直接進入業務處理。
請求存取權杖
NF服務消費者首先應具備可供NRF識別的有效身分和註冊上下文。隨後，它呼叫Nnrf_AccessToken，並指明擬存取的服務、目標NF類型以及自身服務消費者資訊。
NRF根據現有註冊資料和授權策略評估請求。若授權獲准，NRF產生存取權杖並回傳給服務消費者。此時尚未執行訂閱者查詢、工作階段建立或其他業務操作，服務消費者僅取得嘗試呼叫受保護服務的權限。
呼叫受保護服務
服務消費者向NF服務提供者傳送業務請求，並在HTTP Authorization標頭中攜帶存取權杖。服務提供者在處理請求前會驗證權杖的完整性、有效期間和授權宣告，只有所有檢查均通過後才執行所請求的服務。
以PDU工作階段建立為例，AMF首先向NRF的Nnrf_AccessToken服務傳送HTTP/2 POST請求，說明需要存取SMF的Nsmf_PDUSession服務。授權獲准後，NRF在HTTP 200 OK回應中回傳權杖。
隨後，AMF向選定的SMF傳送Nsmf_PDUSession請求並攜帶權杖。SMF在建立PDU工作階段管理上下文之前驗證該憑證。如果請求被接受且上下文建立成功，SMF可以回傳HTTP 201 Created回應。
這一流程將授權置於業務執行之前。僅知道SMF位址和API路徑並不足夠；如果沒有覆蓋目標服務的有效權杖，請求方不應被允許繼續進行正常的工作階段建立。
範圍與設計邊界
基於NRF的服務發現與基於NRF的授權彼此相關，但屬於不同能力。服務發現用於識別可用的服務提供者執行個體及其支援的服務；授權則決定特定服務消費者是否可以呼叫其中某項服務。完成發現並不能免除取得適當權杖的要求。
存取權杖也不能替代業務資料。NRF在核發權杖時不會擷取UDM訂閱資訊，也不會建立SMF工作階段。權杖只是證明服務消費者已在限定範圍內獲得授權，服務提供者仍負責處理請求並產生回應。
安全實現必須在服務提供者側強制執行驗證。如果服務提供者在執行服務前不驗證權杖完整性、有效期限和宣告，那麼要求服務消費者申請權杖幾乎無法提供有效保護。因此，服務消費者、NRF和服務提供者必須遵循相容的權杖處理規則。
授權還受到範圍和時間限制。針對某一SBI服務核發的權杖，並不會自動授予對其他網路功能所有介面的不受限制的存取權。已過期的權杖，或宣告與目標服務不匹配的權杖，都不得被視為有效存取憑證。
因此，NRF在5G核心網路中支援兩類不同的安全相關功能：一是維護NF設定檔並支援服務發現，幫助服務消費者定位合適的服務提供者；二是透過Nnrf_AccessToken控制這些服務消費者是否獲授權呼叫受保護的SBI服務。
常見問題
存取權杖可以替代NF註冊嗎？
不能。NF註冊用於建立執行個體身分及其服務設定檔，存取權杖則為特定的服務存取上下文提供授權。註冊與權杖核發承擔不同作用。
一個權杖可以用於多個NF執行個體嗎？
這取決於權杖宣告、目標NF類型、服務範圍和適用的授權策略。每個服務提供者都必須驗證該權杖是否適用於當前請求，不能僅因權杖尚未過期就直接接受。
NRF無法使用時，已核發權杖會立即失效嗎？
具體行為取決於權杖格式、有效期間、服務提供者側驗證方式和部署策略。NRF暫時中斷並不會自動決定所有已核發權杖的狀態，但新的權杖請求可能會受到影響。
OAuth 2.0會加密SBI訊息內容嗎？
不會。OAuth 2.0主要提供授權和存取控制。SBI傳輸保護由TLS等獨立安全機制實現。有效的存取權杖不能被視為加密傳輸的替代方案。
