Should my app issue it's own access tokens, when using external oauth2 provider (facebook)?

Question

I would like to give the users a possibility to login with some external oauth2 provider (facebook) in my app. The client's part is running on mobile device in a native app.

I am not sure which of the approaches below should I prefer ?

1. Should the client send the user's access token by facebook with each request ? At each request backend asks facebook to validate the access token. Based on the validation's result, backend performs authorization and return corresponding result to the client.

2. Should the backend ask facebook to validate the access token only at user logon, then issue its own access token, return the access token back to the client and client will use this access token at making requests to the server to avoid contacting facebook at each request ?

I have read some questions about how to implement the auth with facebook and most of the devs are using B, but I haven't seen any explanation why is it good/bad to use A ?

What I see as benefits of the solutions:

1. backend doesn't need to care about issuing, refreshing, validating access tokens since this is done only by facebook's authorization servers.
2. this solution seems to be more effective, since it does not require to connect to facebook at each request.

Answer 1

Security tokens issued by Facebook are signed with a digital signature. The API server only needs access to the public key to validate the signature. There's no need at all to contact Facebook after the user authenticates.

A reason to issue your own tokens after the user signed in with Facebook could be to add claims to the token. But obviously having your own authorization server comes at a cost. It's up to you to weigh the pros and cons.

If you do decide to have your own authorization server, make sure not to write your own! There are open source options like Thinktecture IdentityServer.