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?
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
Short Term Token
Now checking Bigquery documentation in this link
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
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