I'm trying to determine whether to use a Token provided by a Third Party service directly, OR issue my own custom Token and store the Third Party Token server side.
User authenticates their identity through a Third Party (social media based login / identity management). To do this they enter their username and password into the Third Party's login page (exposed as a web view in the Client App), and the Third Party returns to the Client App an 'Authorisation Token'.
Client sends the 'Authorisation Token' to my Server, which in combination with a 'Secret Application Key' (provided by the Third Party) let's the Server exchange the user's 'Authorisation Token' for an 'Access Token' (the token I actually need to make API calls on behalf of the user). This happening on the server side allows me to keep my 'Secret Application Key' secret and out of reach of the Client.
At this point I'm unsure whether to either...
- Send the Third Party 'Access Token' to the Client so that it can be included in all future calls to the Server which will then call the Third Party's API, OR
- Send a custom JWT token to the Client, storing the Third Party's 'Access Token' on the Server for each user.
I intend to make all future calls to the Third Party API server side, however my concerns with each option are:
- If the client has their Access Token for the Third Party service, although it only allows access to data for which their account has access, it means they could make additional API calls against my application's call limits.
- If the server holds on to this Third Party Access Token (never sending it to the Client), it creates a resource that is sensitive and must be stored and protected. I would think it would be safer to only temporarily have access to the Access Token when needed.
What is the preferred way of handling this?