4

The GitkitDemo on GitHub says

Now use the idToken to create a session for your user. To do so, you should exchange the idToken for either a Session Token or Cookie from your server. Finally, save the Session Token or Cookie to maintain your user's session.

In the sample code from the answer to the question Validating OAuth2 token obtained on Android device via Google Identity Toolkit (GitkitClient) on 3rd-party backend (custom python backend, non-gae)? the backend-server token verification of the token obtained through Android seems to be enough to ensure having a valid, secure token which can be added to the Android client headers during any follow-up communication with the backend.

So why is there a recommendation to you should exchange the idToken for either a Session Token or Cookie from your server?

Is this due to the size of the idToken (almost 1KB, IIRC)?

Which recommendations exist (the simplest and most secure way) to generate such a Session Token?

Are there any other arguments against using the idToken as a Session Token other than the size?

Can the Session Token be the first part ("token") of the idToken ( idToken.split(".")[0] in Python )? Or the payload (idToken.split(".")[1])? Or maybe creating a SHA1 of the idToken? EDIT: Ok, I realize that using the JTW header would be stupid, but the payload has at least a couple of variables (iat and exp and possibly as well the user_id), but the signature?

The token/cookie created by gitkit.js ("gtoken") is the idToken itself, should that one be replaced by a session token as well?

Community
  • 1
  • 1
Daniel F
  • 13,684
  • 11
  • 87
  • 116

1 Answers1

2

There are several reasons for the recommendation to use your own session token/cookie:

1) Most existing web server frameworks have their own session management mechanism (cookie generation with expiration time etc.). The common approach is to generate a random string as session id, and associate the server-side user activities with the session id. The server then instruct the browser to set a cookie of the session id. It is unnecessary, and sometimes very hard, to replace that mechanism.

2) As you mentioned, the IdToken is much larger than normal session cookies.

3) Currently the Google Identity Toolkit IdToken will expire after two weeks.

Other than these consideration, the IdToken is secure enough as the session token. Be sure -not- to use any sub-part of the IdToken as the session cookie, since attackers can easily create a fake one.

If your server issues its own session cookie, you should delete the gtoken after the user session terminates, so that the Sign In button state of the gitkit.js is kept sync'ed with your server.

Jin Liu
  • 2,203
  • 15
  • 13