原生app登入 後臺方案(token方案)
原來經常用oauth2 的password方案來做登入，自己給自己app做授權沒毛病呀，但後面一下有點不對，這裡應該是有問題的。於是學習了原生app登入的方案。並學習一系列登入有關知識。特此記錄，這是第一篇。
PS:注意，標題中的token即不是oauth2 中的toekn。也不是JSON WEB Token(JWT)中的token
文章目錄
一般情況下，登入方案主要解決三個問題1 登入 2 登入保持 3 登出。
注意以下所有登入方案的 登入及涉及鑑權API都是都是建立https基礎上。
1 web端-session cookies方案
Session 是存放在伺服器端的，類似於Session結構來存放使用者資料，當瀏覽器 第一次傳送請求時，伺服器自動生成了一個Session和一個Session ID用來唯一標識這個Session，並將其通過響應傳送到瀏覽器。當瀏覽器第二次傳送請求，會將前一次伺服器響應中的Session ID放在請求中一併傳送到伺服器上，伺服器從請求中提取出Session ID，並和儲存的所有Session ID進行對比，找到這個使用者對應的Session。
具體實現：
1.1 登入
首先使用者通過post請求提交賬戶密碼到伺服器，伺服器判斷正確後生成一個sessionid，並將sessionid與userid等賬戶資訊一起儲存到記憶體性資料庫(Redis)中，並將sessionid設定到cookies中響應。
1.2 登入保持
下次瀏覽器其他請求就可以從cookies中得到sessionid，從而從資料庫中得到使用者相關資訊，則視為登入成功具有響應許可權。當然我們應該為sessionid設定有效期。
1.3 登出
登出，則從資料中刪除相應sessionid即可，以上即為web端的登入，登入保持，登出 簡單的解決方案。
2 APP端方案 -token
同理，對於app對於APP端，同樣可以採取類似於session的方式實現。嗯，token也是就是sessionid的另一名字。
2.1 APP登入
APP登入也可以生成一個key用來標識該使用者登入成功,因為app沒有cookies的概念，所以這個key(sessionid)不能在儲存到cookies中了。而是通過相應返回給了app，由app儲存，現在它的名字又叫token了。
2.2 登入保持
每次app請求需要驗證登入狀態的api就帶上這個token(請放在header 或body),而伺服器同樣從redis 通過該token得到相應的使用者資訊，來判斷登入。登出過程同樣
2.3 登出
同樣從redis中刪除相應token即可實現登出效果。
PS:注意，這裡token即不是oauth2 中的toekn。也不是JSON WEB Token(JWT)中的token(這東西很難實現登出)。
示意圖：
3 安全性分析
在網上看到很多花裡花哨的RSA加密方案來確保第一次登入賬戶密碼及後續的token不被攔截洩漏。如果登入和後續有許可權操作的API均採用https，則同樣是解決上訴問題(同樣是RSA加密)，當然伺服器資料庫洩漏和app本地token被盜，這種風險就不在本文討論之列。
4 涉及到授權的問題
如果涉及到向三方應用授權，可能就需要部署oauth2授權協議。雖然同樣可以用oauth2 的password為本身app進行授權，但如果oauth2一般情況是沒有部署在redis這種記憶體性資料庫中。每次請求都涉及到鑑權都會操作資料庫，會極大的提高伺服器負載。