If you have an API for which you want to provide authorized access based on the premise of an access token then you should define your own API in the API’s section of the Dashboard and register it with your custom identifier. This means the middleware used to validate the received access token will be using this identifier as part of validation - you’re currently using the /userinfo audience identifier which is incorrect.
Having done this, the client application that is interested in gaining access to the API on behalf of a given end-user should state the previously configured identifier as the value of the audience parameters used in the authentication/authorization request.
The above will mean an access token suitable to be sent to your API can be issued to the client application. By default, that access token will contain the user identifier within the sub claim (currently, the issued access token would be a JWT). However, you can include additional information in the access token by leveraging custom claims; see the reference documentation on how to include custom claims in the access token.