3

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?

1 Answer 1

2

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?

4
  • 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. Jan 1, 2014 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, 2014 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. Jan 1, 2014 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, 2014 at 15:34

You must log in to answer this question.

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