OAuth 2.0 roles, as defined in
Section 1.1 of RFC 6749, are as follows:
-
The Network Repository Function (NRF) shall be the OAuth 2.0 Authorization server.
-
The NF Service Consumer shall be the OAuth 2.0 client.
-
The NF Service Producer shall be the OAuth 2.0 resource server.
OAuth 2.0 client (NF Service Consumer) registration with the OAuth 2.0 authorization server (NRF)
The NF Service registration procedure, as defined in
clause 4.17.1 of TS 23.502, may be used to register the OAuth 2.0 client (NF Service Consumer) with the OAuth 2.0 Authorization server (NRF), as described in
Section 2 of RFC 6749. The client id, used during OAuth 2.0 registration, shall be the NF Instance Id of the NF.
A Network Function that does not implement this option shall be able to get an access token from the NRF as long as the NRF is able to authenticate and authorize the Network Function during the NF access token get service request.
OAuth 2.0 resource server (NF Service Producer) registration with the OAuth 2.0 authorization server (NRF)
The NF Service registration procedure, as defined in
clause 4.17.1 of TS 23.502, shall be used to register the OAuth 2.0 resource server (NF Service Producer) with the OAuth 2.0 Authorization server (NRF). The NF Service Producer, as part of its NF profile, may include
"additional scope" information related to the allowed service operations and resources per NF Service Consumer type.
Step 1.
The NF Service Producer registers as OAuth 2.0 resource server in the NRF. The NF profile configuration data of the NF Service Producer may include the "additional scope". The "additional scope" information indicates the resources and the actions (service operations) that are allowed on these resources for the NF Service Consumer. These resources may be per NF type of the NF Service Consumer or per NF instance ID of the NF Service Consumer.
Step 2-3.
After storing the NF Profile, NRF responds successfully.
The complete service request is a two-step process including requesting an access token by NF Service Consumer (Step 1, i.e. 1a or 1b), and then verification of the access token by NF Service Producer (Step 2).
Step 1: Access token request
Pre-requisite:
-
The NF Service consumer (OAuth2.0 client) is registered with the NRF (Authorization Server).
-
The NF Service Producer (OAuth2.0 resource server) is registered with the NRF (Authorization Server) with optionally "additional scope" information per NF type.
-
The NRF and NF Service Producer share the required credentials.
-
The NRF and NF have mutually authenticated each other.
1a. Access token request for accessing services of NF Service Producers of a specific NF type
The following procedure describes how the NF Service Consumer obtains an access token before service access to NF Service Producers of a specific NF type.
Step 1.
The NF Service Consumer shall request an access token from the NRF in the same PLMN using the
Nnrf_AccessToken_Get request operation. The message shall include the NF Instance Id(s) of the NF Service Consumer, the requested
"scope" including the expected NF Service name(s) and optionally
"additional scope" information (i.e. requested resources and requested actions (service operations) on the resources), NF type of the expected NF Service Producer instance and NF Service Consumer. The NF Service Consumer may also include a list of NSSAIs or list of NSI IDs for the expected NF Service Producer instances.
The message may include the NF Set ID and/or NF Service Set Id of the expected NF Service Producer instances.
The message may include a list of S-NSSAIs of the NF Service Consumer.
Step 2.
The NRF may verify that the input parameters (e.g., NF type) in the access token request match with the corresponding ones in the public key certificate of the NF Service Consumer or those in the NF profile of the NF Service Consumer. The NRF may additionally verify the S-NSSAIs of the NF Service Consumer. The NRF checks whether the NF Service Consumer is authorized to access the requested service(s). For example, the NRF may verify that the NF Service Consumer can serve a slice which is included in the allowed slices for the NF Service Producer. If the NF Service Consumer is authorized, the NRF shall then generate an access token with appropriate claims included. The NRF shall digitally sign the generated access token based on a shared secret or private key as described in
RFC 7515. If the NF Service Consumer is not authorized, the NRF shall not issue an access token to the NF Service Consumer.
The claims in the token shall include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service Consumer (subject), NF type of the NF Service Producer (audience), expected service name(s), (scope), expiration time (expiration) and optionally
"additional scope" information (allowed resources and allowed actions (service operations) on the resources). The claims may include a list of NSSAIs or NSI IDs for the expected NF Service Producer instances. The claims may include the NF Set ID and/or NF Service Set Id of the expected NF Service Producer instances.
Step 3.
If the authorization is successful, the NRF shall send access token to the NF Service Consumer in the
Nnrf_AccessToken_Get response operation, otherwise it shall reply based on Oauth 2.0 error response defined in
RFC 6749. The other parameters (e.g., the expiration time, allowed scope) sent by NRF in addition to the access token are described in
TS 29.510.
The NF Service Consumer may store the received token(s). Stored tokens may be re-used for accessing service(s) from NF Service Producer NF type listed in claims (scope, audience) during their validity time.
1b. Access token request for accessing services of a specific NF Service Producer instance / NF Service Producer service instance
The following steps describes how the NF Service Consumer obtains an access token before service access to a specific NF Service Producer instance / NF Service Producer service instance. 1. The NF Service Consumer shall request an access token from the NRF for a specific NF Service Producer instance / NF Service Producer service instance. The request shall include the NF Instance Id(s) of the requested NF Service Producer, the expected NF Service name, optionally
"additional scope" information (allowed resources and allowed actions (service operations) on the resources) and NF Instance Id of the NF Service Consumer.
Step 2.
The NRF checks whether the NF Service Consumer is authorized to use the requested NF Service Producer instance/NF Service Producer service instance, and then proceeds to generate an access token with the appropriate claims included. If the NF Service Consumer is not authorized, the NRF shall not issue an access token to the NF Service Consumer.
The claims in the token shall include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service Consumer (subject), NF Instance Id or several NF Instance Id(s) of the requested NF Service Producer (audience), expected service name(s) (scope), optionally
"additional scope" information (allowed resources and allowed actions (service operations) on the resources), and expiration time (expiration).
Step 3.
The token shall be included in the Nnrf_AccessToken_Get response sent to the NF Service Consumer. The NF Service Consumer may store the received token(s). Stored tokens may be re-used for accessing service(s) from NF Instance Id or several NF Instance Id(s) of the requested NF Service Producer instance listed in claims (scope, audience) during their validity time.
Step 2: Service access request based on token verification
The following Figure and procedure describe how authorization is performed during Service request of the NF Service Consumer. Prior to the request, the NF Service Consumer may perform
Nnrf_NFDiscovery_Request operation with the requested additional scopes to select a suitable NF Service Producer (resource server) which is able to authorize the Service Access request.
Pre-requisite:
The NF Service Consumer is in possession of a valid access token before requesting service access from the NF Service Producer.
Step 1.
The NF Service Consumer requests service from the NF Service Producer. The NF Service Consumer shall include the access token.
The NF Service Consumer and NF Service Producer shall authenticate each other following
clause 13.3.
Step 2.
The NF Service Producer shall verify the token as follows:
-
The NF Service Producer ensures the integrity of the token by verifying the signature using NRF's public key or checking the MAC value using the shared secret. If integrity check is successful, the NF Service Producer shall verify the claims in the token as follows:
-
It checks that the audience claim in the access token matches its own identity or the type of NF Service Producer. If a list of NSSAIs or list of NSI IDs is present, the NF Service Producer shall check that it serves the corresponding slice(s). If applicable (e.g., when the request is for information related to a specific UE), the NF Service Producer may check that the NF Service Consumer is allowed to access (as indicated by the NF Service Producer's NSSAIs in the access token presented by the NF Service Consumer) at least one of the slice(s) that the UE is currently registered to, e.g., by verifying that the UE's allowed NSSAI(s) intersect with the NF Service Producer's NSSAIs in the access token.
-
If an NF Set ID present, the NF Service Producer shall check the NF Set ID in the claim matches its own NF Set ID.
If an NF Service Set ID present, the NF Service Producer shall check if the NF Service Consumer is authorized to access the requested service according to NF Service Producer Service Set ID in the access token claim.
-
If scope is present, it checks that the scope matches the requested service operation.
-
If the access token contains "additional scope" information (i.e. allowed resources and allowed actions (service operations) on the resources), it checks that the additional scope matches the requested service operation.
-
It checks that the access token has not expired by verifying the expiration time in the access token against the current data/time.
-
If the CCA is present in the service request, it may verify the CCA as specified in clause 13.3.8.3 and that the subject claim (i.e., the NF Instance Id of the NF Service Consumer) in the access token matches the subject claim in the CCA.
Step 3.
If the verification is successful, the NF Service Producer shall execute the requested service and responds back to the NF Service Consumer. Otherwise it shall reply based on Oauth 2.0 error response defined in
RFC 6749.
As described in
clause 6.2.6.1 of TS 23.501, an operator network can deploy multiple NRFs, for example due to network slicing or network segmentation.
An NF Service Consumer shall send its access token requests to the NRF where it is registered as OAuth 2.0 client. The NRF authenticates the NF Service Consumer, and may verify the input parameters in the access token request as described under Step 1 in
clause 13.4.1.1.2. After successful authentication and verification of the input parameters, the NRF may forward the access token request to another NRF.
If an NRF receives an access token request for an NF Service Producer that is not registered at this NRF, the NRF determines the target NRF where the NF Service Producer is registered as specified in
TS 29.510, clause 5.4.2.2.2 step 2a, and forwards the access token request to the target NRF. There can also be several hops of NRFs between the NRF that receives the access token request from the NF Service Consumer and the target NRF where the NF Service Producer is registered.
One possible hierarchical NRF deployment is the local NRF deployment. An NF Service Producer's local NRF is the NRF where the NF Service Producer registered its NF profile. In the local NRF deployment, the NF Service Producer is configured with the public key which corresponds to the private key that its local NRF uses for signing the access token. Thus, when the local NRF receives an access token request from an NF Service Consumer, the local NRF checks if the NF Service Consumer is authorized to receive the requested service and, if yes, issues and signs the access token. In the case when the access token request from the NF Service Consumer was forwarded by another NRF, the local NRF of the NF Service Producer needs to trust the NRF which forwarded the access token request.