Content for  TS 29.501  Word version:  18.4.0

As indicated in TS 33.501 and in clause 6.7.3 of TS 29.500, the access to an 5GC API may be authorized by means of the OAuth 2.0 protocol (see RFC 6749), based on local configuration. OAuth 2.0 supports the concept of scope values to signal which actual access rights an access token represents. Each 5GC API shall define a service-level scope set to the service name of the NF Service. This scope grants generic access to the given API, for those operations on resources that do not require a specific authorization. In addition, a 5GC API may define additional resource/operation-level scopes, that uniquely represents the type of operation (e.g. create/modify/read), the resource and the service; a resource/operation-level scope and the service-level scope, together, grant access to the operations on resources that require a specific authorization. The need for defining additional resource/operation-level scopes in a 5GC API depends on the API functionalities and service operations and on the expected NF service consumers, and thus is up to the API responsible Working Group to decide. The following points may be considered when assessing the need for additional scopes:

• It should be carefully assessed during the design of the 5GC API whether different access rights to the functionalities provided by the API may be needed for different NF service consumers, e.g. considering example NF service consumers of the different service operations supported by the API.
• A 5GC API defined with a service-level scope only, i.e. without additional resource/operation-level scopes, grants access permissions to all its service operations to all NF service consumers allowed to access the service. It should be ensured that designing the API in this way does not cause any vulnerability to the 5GS, e.g. by granting inappropriate read access to sensitive data to undue NF service consumers or by granting inappropriate write (or delete) access to undue NF service consumers.
• Additional scopes should be defined when it is needed to enable restricting the access to certain resource/operations of the 5GC API to specific NF service consumers. This may be the case e.g. when an API supports multiple service operations that may be invoked by different NF service consumers (possibly with different NF types or belonging to different S-NSSAIs, PLMNs or SNPNs), or when it is needed to differentiate access rights for read vs. create/modify/write operations.
• The definition of additional scopes comes with some implementation and network operation complexity. Care should be taken not to increase unreasonably the number of scopes defined in a 5GC API.
• Each additional resource/operation-level scope shall be defined with a clear description (in the main body and in the OpenAPI file of the Technical Specification defining the API) of the access right the additional scope corresponds to. The naming of the resource/operation-level scopes should follow the conventions defined in clause 5.3.16 for ease of understanding and consistency across all 5GC APIs.