0

Is it possible to use client-side and server-side oauth2 authentication without requiring separate user logins for each?

The cross client identity page seems to be exactly what I want, but it doesn't describe how to achieve this for web client and server projects. https://developers.google.com/accounts/docs/CrossClientAuth

Specifically, here is what I'm trying to achieve: I have a web app which uses the drive api to create files and the drive realtime api for collaborative editing of documents, so I need to do client-side authentication. I also want to allow users to publicly share read-only copies of the documents with other users. I want to do this by storing a snapshot of the document data in google app engine that can be read by anyone, but can only be written by the user that created the google doc. This suggests that I need server-side authentication. But is there any way to do this without requiring the user to log in once for the client-side access, then again for the server side access?

This question seems to be similar: Authenticating G+ users on the server side, after client-side login but the accepted answer seems to suggest simply storing the user id on app engine and checking that the user id on the client side matches. That seems like one would only need to know the user id of the file creator to overwrite the document on the app engine server, which is not secure.

Community
  • 1
  • 1
Christopher Best
  • 466
  • 4
  • 14

2 Answers2

2

You can pass the access token of the server component to your front-end in a secure way, you wouldn't need to authorize again on the client side.

Burcu Dogan
  • 9,153
  • 4
  • 34
  • 34
1

It's possibly easier than you think. My app is very similar, in that there is some stuff that I do from a server app, but mostly the user is accessing Drive directly from Javascript.

The way I do it is to do the initial authorisation at the server, as that give me better control over the user experience, and I can combine the Google authorisation with my own signup logic. The result of this is that I end up with a User record in my server database, and a stored access credential.

Once the user is authorised and authenticated, I serve the javascript app, which is then free to do it's own requesting of access tokens, independently of the server. Burcu's answer is correct, you could pass an access token down to the client, but since the client needs to deal with token expiration anyway, I don't see that as a big win (although it can speed up initial loading).

In terms of identification, I store the google user Id in the http session. If ever the client requests some server stuff, it's the session that tells me who the user is (based on Google's private session cookies). So there is no need to pass a user Id down to the client.

pinoyyid
  • 21,499
  • 14
  • 64
  • 115