Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am wondering if it is safe to send "id token", which is one of the items that are result of authenticating a user using Google Open Id Connect, to the client and use it for further authentication.

The other item that is significant is the access token.

My idea was to send the id token to the client, and keep access token only on the server, so that when a user comes next time to the website they can "present" their "id token" and be considered as logged in.

I was wondering if it is a bad idea to send id token over the wire and cache it, or is it acceptable to do that?

share|improve this question

Have you read the OpenID Connect docs thoroughly?

From the documentation:

After obtaining user information from the ID token, you should query your app's user database. If the user already exists in your database, you should start an application session for that user.

I haven't read the docs fully, and I may be wrong here, but you receive the id_token from Google in response to an HTTPS POST

id_token | A JWT that contains identity information about the user that is digitally signed by Google.

so why do you need to 'send' it to the client?

share|improve this answer
Well, I'd like to use the id_token as proof that user has logged in previously ( I plan to send it as part of each HTTP request as one of cookies). I'd like know if sending id token to the client creates a possible attack surface? And yes, I've read the documentation thoroughly a few times, but the documentation does not say anything if the id_token can be safely sent to the client or not. – markovuksanovic Jan 1 '14 at 13:02
It would be more appropriate to use (shorter) session cookies, which do not use the information from id_token or depend only on it. The id_token is not just a number/string but a JSON object that contains more user data, most of which is unnecessary to be sent with each HTTP request. – kedar Jan 1 '14 at 14:16
You maybe right from practicality point of view. But I'm asking here about security and if sendin that token will create some attack surface. – markovuksanovic Jan 1 '14 at 15:26
If you don't have (proper) SSL, then there's the usual issue of MITM and cookie / session stealing. If you parse / use the token improperly, you can have everything from XSS to RCE. The only identifiable information in the token is the email address (with regards to privacy). – kedar Jan 1 '14 at 15:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.