http://blog.csdn.net/newjueqi/article/details/44062849
在很多app中，都需要用戶的登錄操作。登錄，就需要用到用戶名和密碼。為了安全起見，暴露明文密碼的次數越少越好。怎么能最大程度避免泄露用戶的密碼呢？在登錄后，app后端怎么去驗證和維持用戶的登錄狀態呢？在本文中，給出了一套用戶登錄的解決方案，以供大家參考。
1. 保證登錄的安全性，最起碼要使用https協議
避免信息的泄露，最簡單的方案是所有涉及到安全性的api請求，都必須要使用https協議。
HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協議
它是一個安全通信通道，它基於HTTP開發，用於在客戶計算機和服務器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操作，並返回網絡上傳送回的結果。HTTPS實際上應用了Netscape的安 全全套接字層（SSL）作為HTTP應用層的子層。
http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。
注意了，https協議需要到ca申請證書，一般免費證書很少，需要交費。
我們可以看看所有大型網站，例如京東，淘寶，支付寶，涉及到登錄和支付的頁面，url都是以https開頭，這就意味着，這次通訊是使用https。開放平台的api，例如新浪微博，騰訊等，api請求都是以https開頭的。https是業界常用的保證安全性的協議。
因此，涉及安全問題的api，都應該使用https協議。雖然，https為了保證安全性，在效率上是比http協議低。
2. 基本的用戶登錄方案
在傳統的web網站中，可以使用cookie+session來實現用戶的登錄維護，那么在app后端，可以怎么實現呢？
在app后端，怎么避免每次驗證用戶身份都需要傳輸用戶名和密碼呢？
一個生活的模型就是：
假設服務器是個房間，里面有個房間管理員，房間上的門有把鎖，這把鎖有兩種打開方式:
1. 輸入了這把鎖上注冊的用戶名和密碼，就能打開
2. 用房間管理員提供的鑰匙打開
a.當第一次使用用戶名和密碼打開了這把鎖后，進入房間，找到房間管理員，讓他提供一把鑰匙。
b.那以后每次需要進入這個房間，就用這把鑰匙就行了，不用擔心旁邊有人偷看到自己的用戶名和密碼.
c.決定有一段時間不進入這個房間，又怕鑰匙被偷，就進入房間里，把鑰匙還給管理員，讓管理員把鑰匙毀滅
a就是登錄的操作，ｂ就是驗證身份的操作，ｃ就是退出登錄的操作.
理論版的描述如下：
(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在通訊中泄漏的方案。
=======================
https://segmentfault.com/q/1010000005775099
從根源上來講，防止惡意攻擊就需要驗證手機號才能注冊
首先你要明確，Token是用於登錄后驗證身份的，所以一開始就否決了你期待用它來做防惡意注冊，這兩者完全不搭嘎。
其次，要說Token與Session有什么區別，那區別就在於Token更具有定制型，因為它是由你實現的，就能干很多Session不方便干的事情，比如更好的做設備認證，更方便的控制有效期，更好的跨平台性……最重要的，HTTP協議本身定義就是無狀態的，而Cookie這種東西的存在無疑有損無狀態這個定義，所以幾乎所有的接口都拒絕使用Cookie，棄了Cookie，那Token自然成了驗證的首選。
最后，Token的安全性着重於其不會被破解，不會被篡改，而不在於它傳輸時會不會被截取造成中間者攻擊。截取的防護應該是由你加強傳輸過程中的安全性來實現的，比如增加參數簽名，或者直接上HTTPS。
===============================================
http://blog.majiawei.com/2016/06/18/api-auth/
生成簽名
使用分配好的token + 請求URL + 時間戳 + 隨機字符串 做混淆得到一個字符串。這里說明下為什么要加一個時間戳，是為了確保本次API請求的URL只能在一定的時間限定范圍內被使用，防止被第三方非法重復調用的問題。最終構成的請求URL可能長這樣https://api.mjw.com/post/list?uid=xxtimestamp=1425888757&sign=xxxx
http://keeganlee.me/post/architecture/20160107
安全機制的設計
現在，大部分App的接口都采用RESTful架構，RESTFul最重要的一個設計原則就是，客戶端與服務器的交互在請求之間是無狀態的，也就是說，當涉及到用戶狀態時，每次請求都要帶上身份驗證信息。實現上，大部分都采用token的認證方式，一般流程是：
- 用戶用密碼登錄成功后，服務器返回token給客戶端；
- 客戶端將token保存在本地，發起后續的相關請求時，將token發回給服務器；
- 服務器檢查token的有效性，有效則返回數據，若無效，分兩種情況：
- token錯誤，這時需要用戶重新登錄，獲取正確的token
- token過期，這時客戶端需要再發起一次認證請求，獲取新的token
然而，此種驗證方式存在一個安全性問題：當登錄接口被劫持時，黑客就獲取到了用戶密碼和token，后續則可以對該用戶做任何事情了。用戶只有修改密碼才能奪回控制權。
如何優化呢？第一種解決方案是采用HTTPS。HTTPS在HTTP的基礎上添加了SSL安全協議，自動對數據進行了壓縮加密，在一定程序可以防止監聽、防止劫持、防止重發，安全性可以提高很多。不過，SSL也不是絕對安全的，也存在被劫持的可能。另外，服務器對HTTPS的配置相對有點復雜，還需要到CA申請證書，而且一般還是收費的。而且，HTTPS效率也比較低。一般，只有安全要求比較高的系統才會采用HTTPS，比如銀行。而大部分對安全要求沒那么高的App還是采用HTTP的方式。
我們目前的做法是給每個接口都添加簽名。給客戶端分配一個密鑰，每次請求接口時，將密鑰和所有參數組合成源串，根據簽名算法生成簽名值，發送請求時將簽名一起發送給服務器驗證。類似的實現可參考OAuth1.0的簽名算法。這樣，黑客不知道密鑰，不知道簽名算法，就算攔截到登錄接口，后續請求也無法成功操作。不過，因為簽名算法比較麻煩，而且容易出錯，只適合對內的接口。如果你們的接口屬於開放的API，則不太適合這種簽名認證的方式了，建議還是使用OAuth2.0的認證機制。
我們也給每個端分配一個appKey，比如Android、iOS、微信三端，每個端分別分配一個appKey和一個密鑰。沒有傳appKey的請求將報錯，傳錯了appKey的請求也將報錯。這樣，安全性方面又加多了一層防御，同時也方便對不同端做一些不同的處理策略。
另外，現在越來越多App取消了密碼登錄，而采用手機號+短信驗證碼的登錄方式，我在當前的項目中也采用了這種登錄方式。這種登錄方式有幾種好處：
- 不需要注冊，不需要修改密碼，也不需要因為忘記密碼而重置密碼的操作了；
- 用戶不再需要記住密碼了，也不怕密碼泄露的問題了；
- 相對於密碼登錄其安全性明顯提高了。