Most of the scopes available to call Management API can only be obtained via a client credentials grant (https://auth0.com/docs/api/management/v2/tokens). The scope read:users would be an example of a scope that required client credentials; this means that you can’t obtain a valid access token to call an endpoint that requires that scope through an end-user based authentication request.
In addition, given this is a native application which is an OAuth 2.0 public client you won’t be able to perform client credentials from that application. Based on the scopes you’re requesting your goal seems to be obtaining end-user access tokens associated with a social provider. You can technically achieve this by having a back-end you control perform the client credentials grant, however, you would need to be very careful about these access tokens and the general recommendation would be to not surface them to a native client application.
In conclusion, if the use case assumption above is correct you should likely have a back-end API in the middle to handle social provider access tokens obtained as part of a login and use them to perform actions, but never exposing the access token itself to the native client. Also, you would still need to ensure proper authentication and authorization in your back-end API, but at least you would not expose the tokens directly.
Finally, if you’re wondering why go through that if I’ll likely need to obtain a different access token to call the back-end API which in turn will use the social access token to do some action. The reason is that the social providers access tokens obtained as part of a login were obtained through a back-end flow where client authentication could be performed; due to this the access token may have characteristics that are not suitable for a public client (for example, an extended lifetime).