与传统B/S模式的Web系统不同，移动端APP与服务器之间的接口交互一般是C/S模式，这种情况下如果涉及到用户登录的话，就不能像Web系统那样依赖于Web容器来管理Session了，因为APP每发一次请求都会在服务器端创建一个新的Session。而有些涉及到用户隐私或者资金交易的接口又必须确认当前用户登录的合法性，如果没有登录或者登录已过期则不能进行此类操作。
我见过一种“偷懒”的方式，就是在用户第一次登录之后，保存用户的ID在本地存储中，之后跟服务器交互的接口都通过用户ID来标识用户身份。
这种方式主要有两个弊端：
只要本地存储的用户ID没有被删掉，就始终可以访问以上接口，不需要重新登录，除非增加有效期的判断或者用户主动退出；
接口安全性弱，因为用户ID对应了数据库里的用户唯一标识，别人只要能拿到用户ID或者伪造一个用户ID就可以使用以上接口对该用户进行非法操作。
用户登录成功后，服务器端按照一定规则生成一个Token令牌，Token是可变的，也可以是固定的（后面会说明）；
将Token作为key，用户信息作为value放到缓存中，设置有效时长（比如30分钟内没有访问就失效）；
将Token返回给APP端，APP保存到本地存储中以便请求接口时带上此参数；
通过拦截器拦截所有涉及到用户隐私安全等方面的接口，验证请求中的Token参数合法性并检查缓存是否过期；
验证通过后，将Token值保存到线程存储中，以便当前线程的操作可以通过Token直接从缓存中索引当前登录的用户信息。
综上所述，APP端要做的事情就是登录并从服务器端获取Token存储起来，当访问用户隐私相关的接口时带上这个Token标识自己的身份。服务器端要做的就是拦截用户隐私相关的接口验证Token和登录信息，验证后将Token保存到线程变量里，之后可以在其它操作中取出这个Token并从缓存中获取当前用户信息。这样APP不需要知道用户ID，它拿到的只是一个身份标识，而且这个标识是可变的，服务器根据这个标识就可以知道要操作的是哪个用户。
对于Token是否可变，处理细节上有所不同，效果也不一样。
Token固定的情况：服务器端生成Token时将用户名和密码一起进行MD5加密，即MD5(username+password)。这样对于同一个用户而言，每次登录的Token是相同的，用户可以在多个客户端登录，共用一个Session，当用户密码变更时要求用户重新登录；
Token可变的情况：服务器端生成Token时将用户名、密码和当前时间戳一起MD5加密，即MD5(username+password+timestamp)。这样对于同一个用户而言，每次登录的Token都是不一样的，再清除上一次登录的缓存信息，即可实现唯一用户登录的效果。
为了保证同一个用户在缓存中只有一条登录信息，服务器端在生成Token后，可以再单独对用户名进行MD5作为Seed，即MD5(username)。再将Seed作为key，Token作为value保存到缓存中，这样即便Token是变化的，但每个用户的Seed是固定的，就可以通过Seed索引到Token，再通过Token清除上一次的登录信息，避免重复登录时缓存中保存过多无效的登录信息。
本文转载至http://www.myexception.cn/Java-other/2044891.html
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
