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.
在来自问题Validating OAuth2 token obtained on Android device via Google Identity Toolkit (GitkitClient) on 3rd-party backend (custom python backend, non-gae)?的答案的示例代码中,通过Android获得的令牌的后端服务器令牌验证似乎足以确保具有有效的安全令牌,该令牌可以在任何后续通信期间添加到Android客户端头部与后端.
那么为什么有人建议您从服务器交换idToken作为会话令牌或Cookie?
这是由于idToken的大小(几乎1KB,IIRC)?
存在哪些建议(最简单和最安全的方式)来生成这样的会话令牌?
是否有任何其他论据反对将idToken用作会话令牌而不是大小?
会话令牌能否成为idToken的第一部分(“令牌”)(Python中的idToken.split(“.”)[0])?还是有效载荷(idToken.split(“.”)[1])?或者也许创建idToken的SHA1?编辑:好的,我意识到使用JTW头是愚蠢的,但有效载荷至少有几个变量(iat和exp,可能还有user_id),但签名?
由gitkit.js(“gtoken”)创建的令牌/ cookie是idToken本身,是否应该用会话令牌替换?
最佳答案 建议使用您自己的会话令牌/ cookie有几个原因:
1)大多数现有的Web服务器框架都有自己的会话管理机制(带有过期时间的cookie生成等).常见的方法是生成随机字符串作为会话ID,并将服务器端用户活动与会话ID相关联.然后,服务器指示浏览器设置会话ID的cookie.替换该机制是不必要的,有时甚至是非常困难的.
2)正如您所提到的,IdToken比普通会话cookie大得多.
3)目前,Google Identity Toolkit IdToken将在两周后过期.
除了这些考虑之外,IdToken作为会话令牌足够安全.请确保 – 不要将IdToken的任何子部分用作会话cookie,因为攻击者可以轻松创建一个虚假的部分.
如果您的服务器发出自己的会话cookie,则应在用户会话终止后删除gtoken,以便gitkit.js的登录按钮状态与您的服务器保持同步.