方案一 （客戶端token方式）
客戶端生成token傳給服務端校驗，一致就通過用戶驗證。 通過時間戳+用戶唯一標識+MD5加密=token(算法自定義),并且把時間戳傳給后臺，后臺通 過后臺系統的時間戳和客戶端傳過去的時間戳可以規定當前用戶在1分鐘內這次接口可以正常使用，也就是 說，當黑客從路由獲取到連接后，只有1分鐘的時間可以使用這次接口(時間后臺可以自定義)，這樣很大程度 上確保了接口的安全性，同時，這種方式也可以有效的解決用戶登入過期，也就是使用session的方式的不足，但是有個問題，如果客戶端和服務端系統時間不一致，就不能這樣用了，所以這個時間戳如何獲取，也是一個關鍵點，可能通過接口從后臺接口獲取，也可以使用其他方式，有好的建議可以一起探討
方案二 (服務端token方式-session)
這種方式用得是最多的，但是有個前提，用戶登入接口一定要安全，也就是各種加密處理登入，后臺返回sessionId作為token，客戶端攜帶token命牌請求接口，后臺從session中拿到sessionId和參數中的sessionId去驗證一致性通過用戶驗證，這樣其他人就算拿到這個鏈接通過其他客戶端去調接口是不會成功的，因為每個客戶端的session是不一樣的，那么這種方式的缺點就是sessin過期的問題，客戶端用戶調接口時有可能登入已經過期了，解決的辦法就是接口規范了，也就是后臺要返回用戶登入是否過期的字段，客戶端通過這個字段判斷是否跳轉到登入頁面。這種處理方式也是和網站的處理方式差不多一致的
以上兩種方式是用戶需要登入APP的用戶數據安全問題解決辦法
另外，對于接口參數加密處理是一般性的安全問題，以免太多數據信息暴露給外界，防止別人篡改參數拿去調接口，所以參數加密再配合上述兩種方式去做接口安全，是很有意義的。
在app開放接口api的設計中，避免不了的就是安全性問題，因為大多數接口涉及到用戶的個人信息以及一些敏感的數據，所以對這些接口需要進行身份的認證，那么這就需要用戶提供一些信息，比如用戶名密碼等，但是為了安全起見讓用戶暴露的明文密碼次數越少越好，我們一般在web項目中，大多數采用保存的session中，然后在存一份到cookie中，來保持用戶的回話有效性。但是在app提供的開放接口中，后端服務器在用戶登錄后如何去驗證和維護用戶的登陸有效性呢，以下是參考項目中設計的解決方案，其原理和大多數開放接口安全驗證一樣，如淘寶的開放接口token驗證，微信開發平臺token驗證都是同理。
簽名設計
對于敏感的api接口，需使用https協議
https是在http超文本傳輸協議加入SSL層，它在網絡間通信是加密的，所以需要加密證書。
https協議需要ca證書，一般需要交費。
簽名的設計
原理：用戶登錄后向服務器提供用戶認證信息（如賬戶和密碼），服務器認證完后給客戶端返回一個Token令牌，用戶再次獲取信息時，帶上此令牌，如果令牌正取，則返回數據。對于獲取Token信息后，訪問用戶相關接口，客戶端請求的url需要帶上如下參數：
時間戳：timestamp
Token令牌：token
然后將所有用戶請求的參數按照字母排序（包括timestamp，token），然后更具MD5加密（可以加點鹽），全部大寫，生成sign簽名，這就是所說的url簽名算法。然后登陸后每次調用用戶信息時，帶上sign，timestamp，token參數。
例如：原請求https://www.andy.cn/api/user/update/info.shtml?city=北京 （post和get都一樣，對所有參數排序加密）
加上時間戳和token
https://www.andy.cn/api/user/update/info.shtml?city=北京×tamp=12445323134&token=wefkfjdskfjewfjkjfdfnc
然后更具url參數生成sign
最終的請求如
https://www.andy.cn/api/user/update/info.shtml?city=北京×tamp=12445323134&token=wefkfjdskfjewfjkjfdfnc&sign=FDK2434JKJFD334FDF2
其最終的原理是減小明文的暴露次數；保證數據安全的訪問。
具體實現如下：
- api請求客戶端想服務器端一次發送用用戶認證信息（用戶名和密碼），服務器端請求到改請求后，驗證用戶信息是否正確。
如果正確：則返回一個唯一不重復的字符串（一般為UUID），然后在Redis（任意緩存服務器）中維護Token----Uid的用戶信息關系，以便其他api對token的校驗。
如果錯誤：則返回錯誤碼。
2.服務器設計一個url請求攔截規則
（1）判斷是否包含timestamp，token，sign參數，如果不含有返回錯誤碼。
（2）判斷服務器接到請求的時間和參數中的時間戳是否相差很長一段時間（時間自定義如半個小時），如果超過則說明該 url已經過期（如果url被盜，他改變了時間戳，但是會導致sign簽名不相等）。
（3）判斷token是否有效，根據請求過來的token，查詢redis緩存中的uid，如果獲取不到這說明該token已過期。
（4）根據用戶請求的url參數，服務器端按照同樣的規則生成sign簽名，對比簽名看是否相等，相等則放行。（自然url簽名 也無法100%保證其安全，也可以通過公鑰AES對數據和url加密，但這樣如果無法確保公鑰丟失，所以簽名只是很大程 度上保證安全）。
（5）此url攔截只需對獲取身份認證的url放行（如登陸url），剩余所有的url都需攔截。
3.Token和Uid關系維護
對于用戶登錄我們需要創建token--uid的關系，用戶退出時需要需刪除token--uid的關系。
