2

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?

Ozgur Akcali
  • 5,264
  • 2
  • 31
  • 49
  • Hi @Ozgur, I feel this is a bit off-topic question and a very general security question, not necessarily related to BigQuery. Saying that as a thumb roll, I always suggest/prefer to store a token on the server side and use server-side logic as this is much more secure for many reasons. – Tamir Klein Apr 20 '19 at 07:51
  • @TamirKlein thanks a lot for your feedback. I would also normally go with stroring a token on the backend, but it would require getting offline access permission from users, which I do not want. That's why I'm trying to use the token acquired on the client side. – Ozgur Akcali Apr 20 '19 at 10:39

1 Answers1

1

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

Community
  • 1
  • 1
Tamir Klein
  • 3,514
  • 1
  • 20
  • 38
  • I'll check again but AFAIK, applications do not receive refresh tokens unless they request offline access permission – Ozgur Akcali Apr 20 '19 at 12:54
  • I added a bit more details to my answer. Anyway, bottom line I don't think you should store refresh token / long term access details on the client side hope this makes sense to you – Tamir Klein Apr 20 '19 at 14:31
  • Hi @OzgurAkcali, wanted to know if my answer helped you in any way? – Tamir Klein Apr 28 '19 at 13:03