Passing Google access token from client to server

708 views Asked by At

I have an application integrated with Google services (Google Bigquery API to be specific.)

I am authenticating the user on the client side, without offline access scopes (hence without refresh tokens), and doing most of the operations on the client side. But there are some operations I want to do on the server side (still on the authenticated user's behalf.)

Currently, I am passing access tokens to the server side (over https), initializing Google libraries on the server side with this token, and doing the operations there.

The documentations I've found on Google regarding this are either using authentication on the server side, with refresh tokens or completely on the client side. Could not find a documentation suggesting best practices for this mixed case.

In short, what I want to do is, using short lived access tokens acquired on the client side on the backend.

Are there any security risks with this approach? And regardless of that, is this the suggested way of doing what I want?

1

There are 1 answers

3
Tamir Klein On

Regardless of BigQuery oAuth2 implementation, the market general security best practice is to store ONLY short term Security Token on the client side. Even that might be a challenge depending on your client security technique and framework.

Two important points from the official OAuth 2.0 Authorization Framework: Bearer Token Usage

Token storage

Don't store bearer tokens in cookies: Implementations MUST NOT store bearer tokens within cookies that can be sent in the clear (which is the default transmission mode for cookies). Implementations that do store bearer tokens in cookies MUST take precautions against cross-site request forgery.

Short Term Token

Issue short-lived bearer tokens: Token servers SHOULD issue short-lived (one hour or less) bearer tokens, particularly when issuing tokens to clients that run within a web browser or other environments where information leakage may occur. Using short-lived bearer tokens can reduce the impact of them being leaked.

Now checking Bigquery documentation in this link

enter image description here

Their recommendation is: Save refresh tokens in secure long-term storage which are typically not done on client side storage framework.

Since you always get a refresh Token from BigQuery oAuth2 API you can use it on all your API call, done on the server side, thus giving the user a seamless secure flow. Check this in google oauthplayground

enter image description here

BTW: Typically doing call from the client side is for performance reasons, In BigQuery case since it's a big data solution I feel the extra few seconds involve in server-side calls are less important