这只是网上看来的后期可能还会修改。
理论版的描述如下：
(1) 服务器接收到app发送的用户名和密码后，验证用户名和密码是否正确。
如果错误则返回错误信息。
如果验证正确，生成一个随机的不重复的token字符串（例如"daf32da456hfdh"），在redis或memcache中维护一个映视 表，建立token字符串和用户信息的对应关系表，例如，把token字符串"daf32da456hfdh"和用户id"5"对应起来。
(2) 服务器把token字符串返回给app，app把这个token字符串保存起来，作为登录的验证。
(3) 当需要验证用户身份的操作时，必须要把token字符串传给服务器验证身份。
例如，api "test.com/user/update"是更新用户的信息，必须要验证用户的身份.当调用api "test.com/user/update"时，把token字符串"daf32da456hfdh"放在url上，变成"test.com/user /update?token=daf32da456hfdh" .
当服务器接收到这个api请求，知道要验证用户身份的，于是，就把参数中token的值"daf32da456hfdh"取出来，在(1)中建立的 token字符串和用户信息的对应关系表查找，如果发现没这个token值的，则返回验证失败的信息。如果发现有这个token值，则获取这个用户的信 息,进行相关的更新操作。
(4) 当用户退出登录时，需要通过调用api，让服务器把这个用户对于的token字符串删除.
例如，api "test.com/user/logout"是退出登录的api,也要验证用户身份， 则调用"test.com/user/logout?token=daf32da456hfdh" 。当服务器接到退出登录的api请求时，在(1)中建立的token字符串和用户信息的对应关系表查找token字符串，把token和用户信息都删除即 可。
注意：这个方案并不是十分安全，这个身份验证是依赖于token字符串。如果用户泄漏了自己的url, 那很大程度上token也被别人泄漏了，就相当于钥匙被人复制了一份。在下篇的通讯安全中，会描述一个防止token在通讯中泄漏的方案。
