What should be authentication strategy between client and server when only social providers login authentication is used?

Given the following conditions:

1. A website only uses social providers in order to authenticate users (Google/Facebook). There's no native authentication.
2. Only some sections (e.g. product reviews) are restricted.
3. The website communicates with the server (same domain).

What would be the best authentication strategy?

---

- Only use social providers

In this case:

1. We need to research the refresh/revoke token mechanism per each provider and implement it.

---

- Use social providers in order to verify the user is real but use native token

In this case:

1. We verify once that the user is real using the social provider.
2. We generate our own token and send it to the client.

---

It seems to me that the second approach is much better because:

1. There's no need to research how to get refresh tokens depending on each social provider.
2. Our server is in total control: expiration time control.
3. Revoking token is easier as well (e.g. change the secret in our own server).
4. Error handling is easier because there's no need to handle error cases when refreshing tokens from social providers, rather our own error handling can be implemented.
5. If the user closes window social provider refresh token will expire in a few hours while our token will not.
6. If social providers tokens are used then they will be sent from client to server on every request which is a higher security risk than our own token (there's much more user sensitive data in google/facebook than in our website). Also they will have to be saved somewhere in the client for persistance and again this will be a higher security risk.
7. Social providers tokens don't carry any user information specific to our server. This means more frequent queries to our database in order to identify the user instead of just putting our user id in the token (JWT token perhaps).

The biggest disadvantage to me is that we have to maintain multiple refresh/revoke mechanisms per each social providers instead of just one (our own).

It would be interesting what would be the best practice in such case.

Federated sign in feels like the best option, which should meet the goals you've described above:

• During login the app redirects to your authorization server (AS)
• The AS redirects to a Social Identity Provider - eg Facebook
• The user logs in with Facebook credentials
• The social provider posts a token to the AS
• The AS generates its own tokens to return to the app
• Your app identifies users from an AS user id in the token
• The social provider is not used until the next login

As an example, here is a link to the AWS Solution, where each app can select the social providers it supports, and the default Cognito sign in option can be disabled if needed.