在網(wǎng)絡(luò)世界中，安全是一個(gè)很重要的問(wèn)題，以往的HTTP請(qǐng)求已經(jīng)不能承擔(dān)這個(gè)安全任務(wù)，抓包工具一抓，你的所有網(wǎng)絡(luò)請(qǐng)求全都曝光。當(dāng)然，你可能會(huì)采用加密算法來(lái)加密數(shù)據(jù)，但是這仍然不夠。

在移動(dòng)端和服務(wù)器的通信過(guò)程中，有兩種認(rèn)證方式：token和session。

Session: 每個(gè)用戶經(jīng)過(guò)我們的應(yīng)用認(rèn)證之后，我們的應(yīng)用都要在服務(wù)端做一次記錄，以方便用戶下次請(qǐng)求的鑒別，通常而言session都是保存在數(shù)據(jù)庫(kù)和內(nèi)存中，而隨著認(rèn)證用戶的增多，服務(wù)端的開銷會(huì)明顯增大。

擴(kuò)展性: 用戶認(rèn)證之后，服務(wù)端做認(rèn)證記錄，如果認(rèn)證的記錄被保存在內(nèi)存中的話，這意味著用戶下次請(qǐng)求還必須要請(qǐng)求在這臺(tái)服務(wù)器上,這樣才能拿到授權(quán)的資源，這樣在分布式的應(yīng)用上，相應(yīng)的限制了負(fù)載均衡器的能力。這也意味著限制了應(yīng)用的擴(kuò)展能力。

__CSRF: __因?yàn)槭腔赾ookie來(lái)進(jìn)行用戶識(shí)別的, cookie如果被截獲，用戶就會(huì)很容易受到跨站請(qǐng)求偽造的攻擊。CSRF攻擊是源于WEB的隱式身份驗(yàn)證機(jī)制！WEB的身份驗(yàn)證機(jī)制雖然可以保證一個(gè)請(qǐng)求是來(lái)自于某個(gè)用戶的瀏覽器，但卻無(wú)法保證該請(qǐng)求是用戶批準(zhǔn)發(fā)送的！

基于token的鑒權(quán)機(jī)制
基于token的鑒權(quán)機(jī)制類似于http協(xié)議也是無(wú)狀態(tài)的，它不需要在服務(wù)端去保留用戶的認(rèn)證信息或者會(huì)話信息。這就意味著基于token認(rèn)證機(jī)制的應(yīng)用不需要去考慮用戶在哪一臺(tái)服務(wù)器登錄了，這就為應(yīng)用的擴(kuò)展提供了便利。

流程上是這樣的：

• 用戶使用用戶名密碼來(lái)請(qǐng)求服務(wù)器
• 服務(wù)器進(jìn)行驗(yàn)證用戶的信息
• 服務(wù)器通過(guò)驗(yàn)證發(fā)送給用戶一個(gè)token
• 客戶端存儲(chǔ)token，并在每次請(qǐng)求時(shí)附送上這個(gè)token值
• 服務(wù)端驗(yàn)證token值，并返回?cái)?shù)據(jù)

這個(gè)token必須要在每次請(qǐng)求時(shí)傳遞給服務(wù)端，它應(yīng)該保存在請(qǐng)求頭里， 另外，服務(wù)端要支持CORS(跨來(lái)源資源共享)策略，一般我們?cè)诜?wù)端這么做就可以了Access-Control-Allow-Origin: *。

那么我們現(xiàn)在回到JWT的主題上。

JWT是啥？

Json web token (JWT), 是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標(biāo)準(zhǔn)（(RFC 7519).該token被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場(chǎng)景。JWT的聲明一般被用來(lái)在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。

JWT長(zhǎng)什么樣？

JWT是由三段信息構(gòu)成的，將這三段信息文本用.鏈接一起就構(gòu)成了Jwt字符串。就像這樣:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHQiOjE0ODg1NTM3OTk5NzIsImlwIjoiMTkyLjE2OC4xMDIuMTk1IiwidGVsIjoiMTMxMjM0NTY3ODkiLCJ0eXBlIjoiMiIsImRldmljZSI6ImVjMGEwOWZhOWRiOTNjNDQ1Mzk1YzcyNmI2OTUyM2YzIiwiaWF0IjoxNDg4NTI0OTk5OTcyfQ.9rl2XwKIMnVCVVKv9GvhTify7P2xhxIITfaSX4tm_78

JWT的構(gòu)成

第一部分我們稱它為頭部（header),第二部分我們稱其為載荷（payload, 類似于飛機(jī)上承載的物品)，第三部分是簽證（signature).

Header

JWT的頭部承載兩部分信息：

聲明類型，這里是JWT
聲明加密的算法 通常直接使用 HMAC SHA256
完整的頭部就像下面這樣的JSON：

{
  'typ': 'JWT',
  'alg': 'HS256'
}

然后將頭部進(jìn)行base64加密（該加密是可以對(duì)稱解密的),構(gòu)成了第一部分.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.

Playload

Token的第二部分是負(fù)載，它包含了claim， Claim是一些實(shí)體（通常指的用戶）的狀態(tài)和額外的元數(shù)據(jù)，有三種類型的claim： reserved , public 和 private .

• Reserved claims: 這些claim是JWT預(yù)先定義的，在JWT中并不會(huì)強(qiáng)制使用它們，而是推薦使用，常用的有 iss（簽發(fā)者） , exp（過(guò)期時(shí)間戳） , sub（面向的用戶） , aud（接收方） , iat（簽發(fā)時(shí)間） 。

• Public claims：根據(jù)需要定義自己的字段，注意應(yīng)該避免沖突

• Private claims：這些是自定義的字段，可以用來(lái)在雙方之間交換信息

負(fù)載使用的例子：

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

上述的負(fù)載需要經(jīng)過(guò) Base64Url編碼后作為JWT結(jié)構(gòu)的第二部分。

Signature

創(chuàng)建簽名需要使用編碼后的header和payload以及一個(gè)秘鑰，使用header中指定簽名算法進(jìn)行簽名。例如如果希望使用HMAC SHA256算法，那么簽名應(yīng)該使用下列方式創(chuàng)建：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)  

簽名用于驗(yàn)證消息的發(fā)送者以及消息是沒有經(jīng)過(guò)篡改的。

完整的JWT

JWT格式的輸出是以 . 分隔的三段Base64編碼，與SAML等基于XML的標(biāo)準(zhǔn)相比，JWT在HTTP和HTML環(huán)境中更容易傳遞。

下列的JWT展示了一個(gè)完整的JWT格式，它拼接了之前的Header， Payload以及秘鑰簽名：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJleHQiOjE0ODg1NTM3OTk5NzIsImlwIjoiMTkyLjE2OC4xMDIuMTk1IiwidGVsIjoiMTMxMjM0NTY3ODkiLCJ0eXBlIjoiMiIsImRldmljZSI6ImVjMGEwOWZhOWRiOTNjNDQ1Mzk1YzcyNmI2OTUyM2YzIiwiaWF0IjoxNDg4NTI0OTk5OTcyfQ.
9rl2XwKIMnVCVVKv9GvhTify7P2xhxIITfaSX4tm_78

如何應(yīng)用

[AFHTTPSessionManager manager].requestSerializer setValue:JWTToken forHTTPHeaderField:@"token"];

在這次demo中我用的是AFN3.0，Xcoede8。

    AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
    manager.responseSerializer = [AFHTTPResponseSerializer serializer];//服務(wù)器返回的是字符串
    NSMutableDictionary *para = [[NSMutableDictionary alloc] init];
    [para setValue:userPhoneNumber forKey:@"ac_id"];//用戶手機(jī)號(hào)
    [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];//服務(wù)器給我們的是一個(gè)二進(jìn)制流字符串，先將其轉(zhuǎn)化成NSString
        
    NSString *decodeStr = [RSACode decryptString:resonseString publicKey:PUBLICKEY];//服務(wù)器給我的數(shù)據(jù)經(jīng)過(guò)了RSA加密，這里用公鑰進(jìn)行解密
    NSDictionary *dicObject = [RSACode dictionaryWithJsonString:decodeStr];//解密后得到的是一個(gè)字符串，將其轉(zhuǎn)換成字典
    NSMutableArray *resultJson = [dicObject objectForKey:@"result"];

    [[NSUserDefaults standardUserDefaults] setValue:[[resultJson firstObject]objectForKey:@"jwtToken"] forKey:RME_DEVICE_JWT];//通過(guò)NSUserDefaults將token進(jìn)行永久化存儲(chǔ)
    [self.requestSerializer setValue:[[resultJson firstObject]objectForKey:@"jwtToken"] forHTTPHeaderField:@"token"];//將token放到請(qǐng)求頭      
  
    } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {

    }];

上面講完了JWT，接下來(lái)就是RSA加密。

RSA算法是目前最流行的公鑰密碼算法，它使用長(zhǎng)度可以變化的密鑰。RSA是第一個(gè)既能用于數(shù)據(jù)加密也能用于數(shù)字簽名的算法。 RSA算法的原理如下： 1.隨機(jī)選擇兩個(gè)大質(zhì)數(shù)p和q，p不等于q，計(jì)算N=pq； 2.選擇一個(gè)大于1小于N的自然數(shù)e，e必須與(p-1)×(q-1)互素。 3.用公式計(jì)算出d：d×e = 1 (mod (p-1)×(q-1)) 。 4.銷毀p和q。 最終得到的N和e就是“公鑰”，d就是“私鑰”，發(fā)送方使用N去加密數(shù)據(jù)，接收方只有使用d才能解開數(shù)據(jù)內(nèi)容。
RSA的安全性依賴于大數(shù)分解，小于1024位的N已經(jīng)被證明是不安全的，而且由于RSA算法進(jìn)行的都是大數(shù)計(jì)算，使得RSA最快的情況也比DES慢上好幾倍，這也是RSA最大的缺陷，因此它通常只能用于加密少量數(shù)據(jù)或者加密密鑰。需要注意的是，RSA算法的安全性只是一種計(jì)算安全性，絕不是無(wú)條件的安全性，這是由它的理論基礎(chǔ)決定的。因此，在實(shí)現(xiàn)RSA算法的過(guò)程中，每一步都應(yīng)盡量從安全性方面考慮。

首先通過(guò)Mac終端生成公鑰和私鑰。

RSA公鑰私鑰.png

紅線部分是需要輸入的指令，生成的文件在當(dāng)前目錄下。

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端只要持有公鑰即可，私鑰放于服務(wù)端。這樣在和服務(wù)器進(jìn)行通信的時(shí)候，敏感信息服務(wù)器可以用私鑰將其加密，即使他人拿到數(shù)據(jù)也沒有用。而我們傳給服務(wù)器的數(shù)據(jù)，也可以通過(guò)公鑰去加密，由于公鑰加密的數(shù)據(jù)只有對(duì)應(yīng)的私鑰才能解開，而私鑰只有服務(wù)器才持有，這樣就保證了只有服務(wù)器才能解開加密。這樣就會(huì)使我們和服務(wù)器的通信更加安全可靠。