How to properly organize authorization through social networks in the API for web/mobile?

Question

API

When developing a web application with an API, the question arose about the method of authorization through social services.
As I did it before: an authorization link was generated on the backend, into which the redirect address was sewn, the user logged in and was thrown back along with the token, which was checked on the controller receiving the redirect. Then I took this token and received all the necessary data from the social network using it.
Now, when the API has appeared, a mobile application has been added and the web front is now SPA - it is necessary to redo the authorization mechanism.
Mobile application developers want to get all the information themselves and send the following request to api:
POST /api/users
[email protected]
password=1111111
provider=google
socialId=123123123
As I understand it, even without a token.
Or is it better for the client to receive a token and send it to the backend, which itself will pull out the necessary and information + be sure that the user is really logged into the social network.
I ask you to be able to at least a link that will help to remove the covers =)
Thank you.

Answer 1

there are nuances here. In general, in fact, you only need a token if you plan to interact with the server on behalf of the user (for example, rummage through friends and search for them among existing users). Here it is only important to get all the necessary information and register a user with yourself + link an account. If the mobile workers will send this stuff in this form, then that's fine.
In fact, this approach has a fat plus - you can force people to enter additional information. That is, email, for example, is almost always needed, but the user may refuse and a third-party resource will not provide this information, and if you request information from the server, you will not handle this case normally, or you may have a situation with half-registered users.