注：這篇文章為15.app後端怎麼設計使用者登入方案的修改版，以前的這篇部落格寫得太簡單了，弄得很多同學理解不了，趁著寫書《App後臺開發運維和架構實踐》的機會，把這篇文章重寫了。

App操作中經常涉及使用者登入操作，使用者登入就需要使用使用者名稱和密碼。為了安全起見，在登入的過程中暴露密碼的機會越少越好。

登入過程中怎樣才能最大程度地避免洩露使用者的密碼的可能呢？

使用者登入後，App後臺怎麼去驗證和維持使用者的登入狀態呢？

本節提供了一套使用者登入的解決方案以供讀者參考。

使用HTTPS協議

避免資訊的洩露，最基本的方案是所有涉及安全性的API請求都必須使用HTTPS協議。

HTTPS協議是“HTTP協議”和“SSL/TLS協議”的組合。

SSL是“Secure Sockets Layer”的縮寫，中文稱為“安全套接層”，其是20世紀90年代中期由網景公司設計的。原來在網際網路上使用的 HTTP 協議是明文，存在很多缺點（比如傳輸內容會被偷窺和篡改），發明 SSL協議是為了解決這些問題。到了1999年，SSL協議因為其應用廣泛已經成為網際網路上的事實標準，IETF 就在1999年把SSL協議標準化。SSL協議標準化之後的名稱改為TLS（Transport Layer Security）協議，中文稱為“傳輸層安全協議”。習慣上把這兩者並列稱呼（SSL/TLS），因為這兩者可以視作同一個東西的不同階段。

可以把HTTPS大致理解為“HTTP over SSL”或“HTTP over TLS”。其是一個安全通訊通道，基於HTTP開發，用於在客戶計算機和App後臺之間交換資訊。其使用安全套接字層(SSL)進行資訊交換，簡單來說其是HTTP的安全版。HTTPS實際上應用了安全套接字層（SSL）作為HTTP應用層的子層。

HTTPS的模型如下圖所示。

讀者看看支付寶涉及登入和支付的頁面，URL都是以HTTPS開頭，這就意味通訊是使用HTTPS。國內主流開放平臺的API，例如新浪微博、騰訊等，API請求都是以HTTPS開頭。

HTTPS是業界常用的安全協議，支付寶登入的頁面就是使用了HTTPS協議，如下圖所示。

基本的使用者登入方案

傳統Web網站使用Cookie+Session保持使用者的登入狀態，那麼在App後臺怎麼實現類似的功能呢？在App後臺怎麼避免每次驗證使用者身份都需要傳輸使用者名稱和密碼呢？

解決上面的問題，可以參考下面例子。
把App後臺想象為一個房間，裡面有個房間管理員。同時房間門有一把鎖，這把鎖有兩種開啟方式。

• 輸入了這把鎖上註冊的使用者名稱和密碼。
• 用房間管理員提供的鑰匙。

使用者進入這個房間的流程如下。
（1）使用者第一次輸入鎖上註冊的使用者名稱和密碼開啟這把鎖後進入房間，找到房間管理員，讓其提供一把鑰匙。

（2）以後使用者每次需要進入這個房間用這把鑰匙就行，不用擔心旁邊有人偷看到自己的使用者名稱和密碼，從而導致使用者名稱和密碼的洩露。

（3）使用者決定一段時間內不再進入這個房間，又怕鑰匙被偷，進入房間後把鑰匙還給管理員，讓管理員把鑰匙銷燬。

其中（1）就是使用者的登入操作；（2）就是使用者登入後驗證身份的操作；（3）就是使用者退出登入的操作。

把上面的例子轉換為計算機的操作，描述如下。

（1）App後臺接收到App傳送的使用者名稱和密碼後，驗證使用者名稱和密碼是否正確。如果錯誤則返回錯誤資訊。如果App後臺驗證正確，生成一個隨機的不重複的token字串（例如“daf32da456hfdh”），token字串作為使用者的唯一標識（token就是上面例子中提到的鑰匙）。在Redis中建立token字串和使用者資訊的對應關係，例如，把token字串“daf32da456hfdh”和id為“5”的使用者對應。注意：Redis 的hash資料結構將會在“7.2.2 hash—儲存對像的資料”這節中詳細講解。

（2）App後臺把token字串和使用者資訊返回給App，App儲存這些資料作為以後身份驗證的必備資料。生成token的流程如下圖所示。

（3）需要驗證使用者身份的操作必須要把token字串傳給App後臺驗證身份。

例如，“test.com/user/update”是更新使用者的資訊的API，這個API必須驗證使用者身份，當呼叫API“test.com/user/update”時，把token字串“daf32da456hfdh”附在URL上，變成“test.com/user/update?token=daf32da456hfdh”。

當App後臺接收到這個API請求時，許可權設定中要求驗證使用者身份，於是取出引數中token的值“daf32da456hfdh”，在（1）中建立的token字串和使用者資訊的對應關係中查詢，如果沒發現這個token值，則返回驗證失敗的資訊，如果發現這個token值，則獲取這個使用者的資訊，進行相關的更新操作。

注意：這個方案並不是十分安全，身份驗證依賴token字串。如果使用者洩露了URL，那token也洩露了，這相當於鑰匙被黑客複製了一份。在下一篇“ App通訊安全”中將描述一個防止token在通訊中洩露的方案。

本章內容摘錄自本人出版的書籍《App後臺開發運維和架構實踐》

《App後臺開發運維和架構實踐》的購買連結

京東
噹噹
亞馬遜
互動出版網
天貓

開啟連結 app後端設計–總目錄 ，能檢視本人發表過的所有原創“app後端”文章。

【作者】曾健生
【QQ】190678908
【微信公眾號】 appbackend
【新浪微博】 @newjueqi
【部落格】http://blog.csdn.net/newjueqi