关于token和sessionid的一些说法

最近涉及到一个数据迁移的业务场景，之前对AT有一定的了解，没这么深刻，这次算是比较深的理解。

摘自: bbs 作者：chendejia2012

其实token就相当于sessionId,为什么app喜欢用token，而不用sessionId呢？

app说他们保管cookie不方便，不好维护cookie，因为cookie是浏览器的东西，app天生不支持cookie。我觉得很奇怪，浏览器也会出现关闭cookie的时候，这时，服务器会重写url，将sessionId放到url后面，如果app不打算用cookie，那么与浏览器关闭cookie无异，服务器将sessionId放到url后，app完全可以把sessionId拿出来，缓存到app数据库或者内存中，下次访问服务器就带上sessionId。

服务器默认的sessionId名称叫JSESSIONID，app说他们需要token，那么就把JSESSIONID换一个名称，就叫token，那么服务器和重写url返回sessionId一样，就把token放到url后面就可以了。实际token和JSESSIONID的值是一样的，换汤不换药，然后APP开发会觉得很高兴，他们终于拿到想要的token了。然而对api开发来说，感觉这其实多此一举。

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

那么到底是不是多此一举，token是怎么来的呢？为什么会有token这个说法和用法？

毕竟我相信“存在即合理”

实际如果app后面对应的服务器如果是分布式系统，就需要token了。

因为app需要到登录服务器上登录，然后到应用服务器去获取数据，这里涉及到不同的服务器，那么不同服务器对应到该app客户端的sessionId肯定不一样，app不像浏览器那么强大，管理不同域下的sessionId都很方便，这时app肯定希望有一个统一的sessionId，那就是token，方便访问不同的服务器。

还有一个理由是，应用服务器需要校验当前app是否登录，于是要到登录服务器上去询问，询问时总要带个app的凭证吧，于是需要一个token，这个token是登录服务器给app的，应用服务器拿着这个token去询问登录服务器，登录服务器校验该token后，就会告知应用服务器当前app是否合法（在我这里登录过），然后应用服务器才能放心的把数据返回给app。

大家可以参考单点登录服务器与应用服务器，与客户端的交互，便可知道token的用法了。

实际如果应用服务器同时带登录功能，那么完全可以不必搞个token出来，就沿用sessionId就可以了。如果app非要token，那么可以修改server.xml，把默认JSESSIONID改成token。

经常会看到第三方服务接口，如新浪微博，都需要带上一个access_token，实际新浪微博就相当于一个第三方登录系统，而且心流浪微博后面会有多个分布式系统，系统与系统之间交互肯定需要token，那么新浪微博就会要求客户端带上access_token，而这个access_token是可以通过新浪微博接口获取的，每获取一次，access_token会改变，看来这个access_token就像一个sessionId，可以重置。

至于说经常会有服务器开发和app开发争论token和sessionId谁优谁劣完全没有意思，具体问题具体分析，该用什么就用什么。就好像争论java好还是c好，还是PHP好一样，不同的东西有不同的业务场景。

还是那句话 “ 存在即合理 ”...