4

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.

Authentication flow

  • 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...

    1. 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
    2. 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:

  1. 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.
  2. 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?

Z-Mehn
  • 43
  • 3

1 Answers1

5

the oAuth 2 framework doesn't regulate this aspect, so technically either approach is fine. However, what is usually followed is the one where the server maintains the access token, along with the refresh token (in case of offline access, e.g. in google's oAuth framework).

When you are using a third party authentication, you are using it as an IDP (identity provider) so that you can attach the identity with the user. In addition to that, as restricted by the scopes of the access token, you can access some additional services provided by the third party resource server. After this whatever interaction happens between the client and your server should be managed by your own application's session. You should not use the access token as your session token in your application.

To comment on the drawback with this approach as you remarked:

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.

Even if the access token is given back to your client, you would still have to ensure that it is stored on the client securely. And it is easier to provide that security on server than on client.

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,

This seems to be not a very good idea for the other reason that's it's wholly redundant in this case to route the request through your server. If the client has the access token (which is usually a bearer token), it can directly communicate with the third party resource server. Unless of course the third party server restricts access based on IP whitelisting or such other means. Again in that case it's better to have your own custom session between your client and server and let the server talk to the resource server using the access token that it saves with itself.

Chayan Ghosh
  • 236
  • 1
  • 6