1.介面使用一個key跟用戶id md5加密。然後加密後的sign當參數傳遞（這樣簡單的加密方式安全嗎？）。
2.那麼問題來了，那如果用戶的請求被抓到了，那不是別人也可以模擬請求。那如何知道請求是自己的APP發出的。 如果只是請求頭上帶了app訊息，那其他人也可以模擬。
3.因為介面從app發出，使用者只有抓本地包才能看到這些資訊。現在使用者被別人要求包的情況容易出現嗎？
強烈建議使用ssl來保護web api的通訊安全，自己實作也未嘗不可，但是肯定是沒有ssl安全這是一定的。你這種做法會被中間人監聽，sign直接會被拿到利用。
可以模擬請求。如果對方都反編譯了你的app，鑑權過程都了解了，那麼是絕對可以模擬的。
在沒有ssl保護的情況下http都是明文傳輸，這種情況不是只有本地才能監聽到。如果使用ssl保護通訊安全的話，可以保證不被中間人監聽。關於是否容易出現那就看你這個app的價值了。
推薦題主去了解下：中間人監聽 重播攻擊
之前我看人家是這麼做的，有個專門的介面取得key，key的有效期限是2天。 之後調所有的接口，token直接用key加上對應參數格式，進行md5加密。也就是說參數是不帶任何key的。 一般來說，包會請求很多次，參數都會有變化，token就會不一樣。 而且，就算拿到key，不知道對方的組裝方式也白搭。
可以試試Json Web Token
強烈建議使用ssl來保護web api的通訊安全，自己實作也未嘗不可，但是肯定是沒有ssl安全這是一定的。你這種做法會被中間人監聽，sign直接會被拿到利用。
可以模擬請求。如果對方都反編譯了你的app，鑑權過程都了解了，那麼是絕對可以模擬的。
在沒有ssl保護的情況下http都是明文傳輸，這種情況不是只有本地才能監聽到。如果使用ssl保護通訊安全的話，可以保證不被中間人監聽。關於是否容易出現那就看你這個app的價值了。
推薦題主去了解下：中間人監聽 重播攻擊
之前我看人家是這麼做的，有個專門的介面取得key，key的有效期限是2天。
之後調所有的接口，token直接用key加上對應參數格式，進行md5加密。也就是說參數是不帶任何key的。
一般來說，包會請求很多次，參數都會有變化，token就會不一樣。
而且，就算拿到key，不知道對方的組裝方式也白搭。
可以試試Json Web Token