這只是網上看來的后期可能還會修改。
理論版的描述如下：
(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在通訊中泄漏的方案。