2

I'm trying to write an app that will let a user see multiple Gmail inboxes at one time. I am storing the refresh token for each account in my database.

However, I would like for almost all traffic to and from Gmail to go through the browser - I don't want the unnecessary step of the server retrieving mail and sending it to the client, since I am not going to do anything with the emails server side.

This is the same (or same type of) token that the user would get if I did access token retrieval on the client. So when the user logs in, is it safe to grab an access token server side and send that to the client (over HTTPS of course)? If not, what would be the best practice here?

  • I might even speculate that this is 'more' secure than storing the access token in a cookie or local storage. Users auth with my app via a JWT, then perform a GET to my server for the Gmail access token. So the Gmail access token is never stored anywhere client side. Any corrections?
5
  • Gmail will have defenses against third parties reading or writing its browser-based access tokens, which is what this approach entails, no? Aug 26, 2016 at 4:22
  • @JonahB the flow for this app is: User auths and google sends auth code to browser -> Browser sends HTTP to my server with auth code -> Auth code is used to retrieve access token and refresh token -> My server stores the refresh token in the user database and sends the access token (NOT the refresh token) to the client.
    – Greg Pete
    Aug 26, 2016 at 4:41
  • How does the access token, delivered under custody of your domain, move into the custody of google's domain? Aug 26, 2016 at 5:39
  • @JonahB After the client receives the access token from my server, the client makes standard HTTP requests to google's API endpoints, placing the gmail access token in the Authorization: Bearer header. Is that what you mean?
    – Greg Pete
    Aug 26, 2016 at 7:04
  • There is an implicit breach of trust in trying to do this, see yoricks answer, and technically it is impossible. The gmail client is actually googles javascript delivered from their server. You cannot impersonate this, or interpose credentials, bc of browser security model. If you could, then any third party frame or page, including ones with malicious intent, could similarly interpose. Hope that makes sense Aug 26, 2016 at 10:55

1 Answer 1

2

You cannot do this, and I will explain why. I am assuming we are talking about OAUTH2, which states clearly what you can and cannot do with a token. OAUTH2 divides clients into five categories:

  • Confidential
  • Public
  • web-Application
  • Browser-Application (Client side)
  • Native-Application (Client side)

Each of these use their own authorization methods to obtain the access key (grant types). Before you can query an authorization token at all, you must have registered the application with Google and got an client id (and secret) in return.

Getting to the point; when you registered the client you chose a client category, and I am guessing webapplication (client credential) based on you topic. However, once chosen a type, you promise to use any tokens for that client type only. If you were to send the access token from the server to the client, you break that promise.

OAUTH2 divides client types for a reason, primarily based on security and the ability to keep tokens secret for some time. If you want to store the access token in the client side, then switch to Implicit. Obviously, you cannot use the key on the server for the very same purpose.

The image below demonstrates the differences.

enter image description here

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .