How it Works

This section describes how this role works. The AMF supports OAuth2 client authorization to NRF. It is processed as in the following procedures:

  • Only when the nf-client profile is configured with OAuth2-Enabled , where the value is set to true for a nf-type , the AMF considers those profiles with OAuth2-Enabled as true value.

  • The AMF internally sends the AccessToken request to the NRF server, stores the received token in the cache. The same token is reused until it expires.

  • When the profile is selected and the token is received, the application includes the AccessToken in the Authorization header in the request toward NF producer.

  • If the nf-client profile is not configured, that is when OAuth2 is not enabled on the consumer side, the AMF ignores those profiles with the oauth2Required and selects the producer in the rest of the profiles that are received in the discovery response.

  • For AMF to send an AccessToken request to NRF, endpoints must be configured in the CLI for service type OAuth2 and the same must be set in the profile nf-pair for each type, where OAuth2 is enabled.

  • When OAuth2-Enabled is set to true in the CLI and none of the discovered profiles from NRF has oauth2Required , then no profiles from discovery will be selected. It then reverts to the locally configured profiles. The AccessToken requests will not be sent, as a locally configured profile is assumed to be based on the local trust policy, and NRF has no information about that.

  • When OAuth2-Enabled is set to false in the CLI and all the discovered profiles have oauth2Required enabled, then no profiles in the discovery will be selected. It then reverts to the locally configured profiles. If no profiles are configured locally, then the call fails.