iOS網路請求安全認證(JWT,RSA)
在網路世界中,安全是一個很重要的問題,以往的HTTP請求已經不能承擔這個安全任務,抓包工具一抓,你的所有網路請求全都曝光。當然,你可能會採用加密演算法來加密資料,但是這仍然不夠。
在移動端和伺服器的通訊過程中,有兩種認證方式:token和session。
Session: 每個使用者經過我們的應用認證之後,我們的應用都要在服務端做一次記錄,以方便使用者下次請求的鑑別,通常而言session都是儲存在資料庫和記憶體中,而隨著認證使用者的增多,服務端的開銷會明顯增大。
擴充套件性: 使用者認證之後,服務端做認證記錄,如果認證的記錄被儲存在記憶體中的話,這意味著使用者下次請求還必須要請求在這臺伺服器上,這樣才能拿到授權的資源,這樣在分散式的應用上,相應的限制了負載均衡器的能力。這也意味著限制了應用的擴充套件能力。
__CSRF: __因為是基於cookie來進行使用者識別的,
cookie如果被截獲,使用者就會很容易受到跨站請求偽造的攻擊。CSRF攻擊是源於WEB的隱式身份驗證機制!WEB的身份驗證機制雖然可以保證一個請求是來自於某個使用者的瀏覽器,但卻無法保證該請求是使用者批准傳送的!
基於token的鑑權機制
基於token的鑑權機制類似於http協議也是無狀態的,它不需要在服務端去保留使用者的認證資訊或者會話資訊。這就意味著基於token認證機制的應用不需要去考慮使用者在哪一臺伺服器登入了,這就為應用的擴充套件提供了便利。
流程上是這樣的:
- 使用者使用使用者名稱密碼來請求伺服器
- 伺服器進行驗證使用者的資訊
- 伺服器通過驗證傳送給使用者一個token
- 客戶端儲存token,並在每次請求時附送上這個token值
- 服務端驗證token值,並返回資料
這個token必須要在每次請求時傳遞給服務端,它應該儲存在請求頭裡, 另外,服務端要支援
CORS(跨來源資源共享)
策略,一般我們在服務端這麼做就可以了Access-Control-Allow-Origin: *
。
那麼我們現在回到JWT的主題上。
JWT是啥?
Json web token (JWT), 是為了在網路應用環境間傳遞宣告而執行的一種基於JSON的開放標準((RFC 7519).該token被設計為緊湊且安全的,特別適用於分散式站點的單點登入(SSO)場景。JWT的宣告一般被用來在身份提供者和服務提供者間傳遞被認證的使用者身份資訊,以便於從資源伺服器獲取資源,也可以增加一些額外的其它業務邏輯所必須的宣告資訊,該token也可直接被用於認證,也可被加密。
JWT長什麼樣?
JWT是由三段資訊構成的,將這三段資訊文字用.連結一起就構成了Jwt字串。就像這樣:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHQiOjE0ODg1NTM3OTk5NzIsImlwIjoiMTkyLjE2OC4xMDIuMTk1IiwidGVsIjoiMTMxMjM0NTY3ODkiLCJ0eXBlIjoiMiIsImRldmljZSI6ImVjMGEwOWZhOWRiOTNjNDQ1Mzk1YzcyNmI2OTUyM2YzIiwiaWF0IjoxNDg4NTI0OTk5OTcyfQ.9rl2XwKIMnVCVVKv9GvhTify7P2xhxIITfaSX4tm_78
JWT的構成
第一部分我們稱它為頭部(header),第二部分我們稱其為載荷(payload, 類似於飛機上承載的物品),第三部分是簽證(signature).
Header
JWT的頭部承載兩部分資訊:
宣告型別,這裡是JWT
宣告加密的演算法 通常直接使用 HMAC SHA256
完整的頭部就像下面這樣的JSON:
{ 'typ': 'JWT', 'alg': 'HS256' }
然後將頭部進行base64加密(該加密是可以對稱解密的),構成了第一部分.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
Playload
Token的第二部分是負載,它包含了claim, Claim是一些實體(通常指的使用者)的狀態和額外的元資料,有三種類型的claim: reserved , public 和 private .
-
Reserved claims: 這些claim是JWT預先定義的,在JWT中並不會強制使用它們,而是推薦使用,常用的有 iss(簽發者) , exp(過期時間戳) , sub(面向的使用者) , aud(接收方) , iat(簽發時間) 。
-
Public claims:根據需要定義自己的欄位,注意應該避免衝突
-
Private claims:這些是自定義的欄位,可以用來在雙方之間交換資訊
負載使用的例子:
{ "sub": "1234567890", "name": "John Doe", "admin": true }
上述的負載需要經過 Base64Url
編碼後作為JWT結構的第二部分。
Signature
建立簽名需要使用編碼後的header和payload以及一個祕鑰,使用header中指定簽名演算法進行簽名。例如如果希望使用HMAC SHA256演算法,那麼簽名應該使用下列方式建立:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
簽名用於驗證訊息的傳送者以及訊息是沒有經過篡改的。
完整的JWT
JWT格式的輸出是以 . 分隔的三段Base64編碼,與SAML等基於XML的標準相比,JWT在HTTP和HTML環境中更容易傳遞。
下列的JWT展示了一個完整的JWT格式,它拼接了之前的Header, Payload以及祕鑰簽名:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJleHQiOjE0ODg1NTM3OTk5NzIsImlwIjoiMTkyLjE2OC4xMDIuMTk1IiwidGVsIjoiMTMxMjM0NTY3ODkiLCJ0eXBlIjoiMiIsImRldmljZSI6ImVjMGEwOWZhOWRiOTNjNDQ1Mzk1YzcyNmI2OTUyM2YzIiwiaWF0IjoxNDg4NTI0OTk5OTcyfQ.
9rl2XwKIMnVCVVKv9GvhTify7P2xhxIITfaSX4tm_78
如何應用
[AFHTTPSessionManager manager].requestSerializer setValue:JWTToken forHTTPHeaderField:@"token"]; 在這次demo中我用的是AFN3.0,Xcoede8。 AFHTTPSessionManager *manager = [AFHTTPSessionManager manager]; manager.responseSerializer = [AFHTTPResponseSerializer serializer];//伺服器返回的是字串 NSMutableDictionary *para = [[NSMutableDictionary alloc] init]; [para setValue:userPhoneNumber forKey:@"ac_id"];//使用者手機號 [para setValue:dToken forKey:@"token"];//UUID NSURLSessionDataTask *task = [self httpRequestWithMethod:@"POST" pathUrl:USER_GET_NEW_SESSION_ID_URL parameters:para success:^(NSURLSessionDataTask * _Nonnull task, id _Nullable responseObject) { NSString *resonseString = [[NSString alloc] initWithData:responseObject encoding:NSUTF8StringEncoding];//伺服器給我們的是一個二進位制流字串,先將其轉化成NSString NSString *decodeStr = [RSACode decryptString:resonseString publicKey:PUBLICKEY];//伺服器給我的資料經過了RSA加密,這裡用公鑰進行解密 NSDictionary *dicObject = [RSACode dictionaryWithJsonString:decodeStr];//解密後得到的是一個字串,將其轉換成字典 NSMutableArray *resultJson = [dicObject objectForKey:@"result"]; [[NSUserDefaults standardUserDefaults] setValue:[[resultJson firstObject]objectForKey:@"jwtToken"] forKey:RME_DEVICE_JWT];//通過NSUserDefaults將token進行永久化儲存 [self.requestSerializer setValue:[[resultJson firstObject]objectForKey:@"jwtToken"] forHTTPHeaderField:@"token"];//將token放到請求頭 } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) { }];
上面講完了JWT,接下來就是RSA加密。
RSA演算法是目前最流行的公鑰密碼演算法,它使用長度可以變化的金鑰。RSA是第一個既能用於資料加密也能用於數字簽名的演算法。 RSA演算法的原理如下: 1.隨機選擇兩個大質數p
和q
,p
不等於q
,計算N=pq;
2.選擇一個大於1
小於N
的自然數e
,e
必須與(p-1)×(q-1)
互素。
3.用公式計算出d:d×e = 1 (mod (p-1)×(q-1))
。 4.銷燬p
和q
。 最終得到的N
和e
就是“公鑰”,d
就是“私鑰”,傳送方使用N
去加密資料,接收方只有使用d
才能解開資料內容。
RSA的安全性依賴於大數分解,小於1024位的N
已經被證明是不安全的,而且由於RSA演算法進行的都是大數計算,使得RSA最快的情況也比DES慢上好幾倍,這也是RSA最大的缺陷,因此它通常只能用於加密少量資料或者加密金鑰。需要注意的是,RSA演算法的安全性只是一種計算安全性,絕不是無條件的安全性,這是由它的理論基礎決定的。因此,在實現RSA演算法的過程中,每一步都應儘量從安全性方面考慮。
首先通過Mac終端生成公鑰和私鑰。
RSA公鑰私鑰.png紅線部分是需要輸入的指令,生成的檔案在當前目錄下。
openssl genrsa -out rsa_private_key.pem 1024 pkcs8 -topk8 -inform PEM -in rsa_private_key.pem -outform PEM -nocrypt rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem
生成了公鑰和私鑰之後,我們APP端只要持有公鑰即可,私鑰放於服務端。這樣在和伺服器進行通訊的時候,敏感資訊伺服器可以用私鑰將其加密,即使他人拿到資料也沒有用。而我們傳給伺服器的資料,也可以通過公鑰去加密,由於公鑰加密的資料只有對應的私鑰才能解開,而私鑰只有伺服器才持有,這樣就保證了只有伺服器才能解開加密。這樣就會使我們和伺服器的通訊更加安全可靠。
Session | Token | |
---|---|---|
狀態儲存位置 | 伺服器儲存所有的Session狀態資訊 | 每個客戶端儲存自己的token狀態 |
擴充套件性 | 即使是分散式的佈局方式,也需要到儲存當前Session的伺服器獲取資料 | 任意一臺伺服器均可解析Token |
分享 | 無法分享和授權給其他應用 | 可以很方便的分享和授權給其他應用,而且很安全,無法偽造 |
依賴性 | 通常需要藉助Cookie來實現 | 沒有依賴,加密方式安全就安全 |