App登錄需要解決的問題有兩個：安全、體驗。它們分別對應著登錄過程的用戶認證，以及用戶登錄過程操作復雜度兩個問題。
一、登錄過程的用戶認證，常見的手段有密碼加密傳輸、動態密碼、驗證碼等。
1、密碼加密。
目前互聯網行業的移動APP有不少在使用最簡單的做法：根據密碼生成一個散列值，把散列值發送給服務器。服務器計算庫中用戶密碼的散列值，然后和客戶端傳來的散列值比較，一致的話，登錄成功。
如果安全性要求更高一些的話，常見的做法就是公鑰加密。具體做法是這樣，登錄前先向服務器請求一個公鑰密鑰，用公鑰密鑰加密一串根據密碼生成的散列值，然后發送給服務器。服務器使用私鑰密鑰解密，然后與根據數據庫中的用戶密碼計算出來的散列值進行比較，一致的話，登錄成功。當然，還可以做的更優化一些，就是控制公鑰密鑰的有效期來增強安全性，比如公鑰10秒鐘失效、只能使用一次等。
關于公鑰加密，可以參考這篇文章：http://www.360doc.com/content/11/0406/17/4146412_107621805.shtml
2、動態密碼。
關于動態密碼，其本質就是選擇另外一種可以識別用戶身份唯一性的方式來和用戶的靜態密碼一起做用戶認證。具體常見的幾種實現手段，可以參考這篇文章：http://baike.soso.com/v5973952.htm
目前市面上適合App使用的最常見的方式是利用手機短信進行動態密碼認證。即用戶常規登錄時，如果服務器發現有異常，可以向用戶手機發送一條包含動態密碼的短信，用戶在有效期（常見的是30秒到1分鐘）內把用戶名、用戶密碼、動態密碼一起發送給服務器進行驗證。這個對用戶來說，操作門檻比較低，也很方便。
3、驗證碼。
服務器一旦發現登錄有異常，如IP變化、短時間內登錄次數過多等，會向App下發一個圖片，用戶把圖片中要求輸入的數據和用戶名、用戶密碼一起提交給服務器。
為了降低用戶登錄過程的復雜性，通常情況下，用戶只需要輸入用戶名和密碼，只有服務器發現異常情況才會啟用驗證碼、動態密碼等機制。
二、減少用戶輸入次數的自動登錄。
App登錄成功后，服務器會告訴App一個session，后續交流都使用session。但通常為了安全起見session都是要設置有效期的，從1星期到20天都見過。那么，為了不讓用戶在session失效后重新登錄，減少用戶的手動輸入用戶名和用戶密碼的次數，引入了“自動登錄”概念。
流程如下：
登錄成功后，服務器給App下發sesion的同時，還下發一個認證token，客戶端把token做為應用程序的私有數據存儲起來。以后，每當session過期后，就把token發送給服務器獲取新的session。整個過程都是對用戶透明的，對用戶來說，輸入一次用戶名和密碼后，就再也沒有登錄這個事情了。
當然，這種自動登錄的前提，是能保證token的安全性遠大于session。我們知道，由于手機OS的安全機制，token做為應用程序的私有數據，對其它應用是不可見的，可以保證token的安全性。我們還可以再上一個鎖，把token和用戶使用App的那個設備做綁定。可供選擇的綁定數據有imsi,mac等。這樣的話，只要用戶手機不丟，就沒事。
沒有一種安全機制是絕對安全的，我們需要在實際應用過程中綜合運用App使用場景、具體業務類型、用戶習慣等各種方式來平衡安全性、用戶體驗還有商業應用中很重要的成本。
