How to properly organize authorization on the API server?

Question

Facebook

I am writing an API for a service whose clients will be mobile applications (my own + third-party). For my applications, I use the Resource Owner Password Credentials Grant from the official oAuth 2.0 documentation.
Those. a standard registration form is made in the application (enter email, password), then sent to the server (POST /users), where a user account is created. Next, an endpoint like /auth is sent:

grant_type=password
username=Mike
password=123
client_id=123
client_secret=123

client_id and client_secret do not conform to the oAuth specification, but they are required to identify the client.
If everything is correct, we return the token (in my case, JWT + refresh_token). refresh_token made eternal and I use it only to be able to manually revoke.
Here everything is relatively clear and corresponds well to the official oAuth specification.
Further, the task becomes more difficult. We need the ability for users to register through social networks. I organized the registration as follows: the native application requests access to personal information and receives a social network token, then sends it to the server (POST /users):

social_provider=facebook
social_token=ТОКЕН_ФЕЙСБУКА

Next, the server receives all the necessary information about the user from the social network using the provided token and creates an account. Does it make sense to keep this Facebook token?
And now we need to somehow implement the issuance of our API token for such users registered through social networks. It is clear that such accounts do not have passwords, and using the Resource Owner Password Credentials Grant in its pure form will not work. How to be? Thoughts are spinning towards sending a Facebook token as a password. Based on it, the server will recognize the user's facebook_id and will be able to check if such a user exists in the database. And, accordingly, issue your token.

grant_type=password
username=facebook_user
password=ТОКЕН_ФЕЙСБУКА
client_id=123
client_secret=123

Tell me, are there any better ways, or some flaws in such a scheme?