Android網路請求知識（三）授權，TCP/IP，HTTPS建立過程

1. 授權

定義

由身份或持有的令牌確認享有的許可權，登入過程實質上的目的也是為了確認許可權。

Http中確認授權的方式一：Cookie（目前不常用於授權）

Cookie是客戶端給伺服器用的，setCookie是伺服器給客戶端用的。cookie由伺服器處理，客戶端負責儲存

工作機制:

• 伺服器需要客戶端儲存的內容，放在set-Cookie headers裡返回，客戶端會自動儲存。
• 客戶端儲存的Cookies，會在之後的所有請求裡都攜帶進Cookie header裡發回給伺服器。
• 客戶端儲存Cookie是按照伺服器域名來分類的，例如baidu.com發回的Cookie儲存下來後，之後請求google.com並不會帶上cookie。
• 客戶端儲存的Cookie在超時後會被刪除，沒有設定超時時間的Cookie（稱為Session Cookie）在瀏覽器關閉後就會自動刪除。

Cookie登入：

客戶端傳送cookie：賬戶和密碼
服務端收到後確認登入setCookie：sessionID=1，記下sessionID
客戶端收到sessionID後記錄，以後請求服務端帶上對比記錄下sessionID，說明已經登入

Cookie作用：

會話管理：登入狀態，購物車
個性化：使用者偏好，主題
Tracking：分析使用者行為

Cookie攻擊

XXS：跨指令碼攻擊，及使用JavaScript拿到瀏覽器的cookie之後，傳送到自己的網站，以這種方式來盜用使用者Cookie。Server在傳送Cookie時，敏感的Cookie加上HttpOnly，這樣Cookie只能用於http請求，不能被JavaScript呼叫
XSRF:跨站請求偽造。Referer 從哪個網站跳轉過來

Http中確認授權的方式二：Authorization

兩種方式：Basic和Bearer

Basic

• 格式：Authorization:Basic<username:password(Base64ed)>

Bearer

• 格式：Authorization:Bearer<bearer token>
• bearer token獲取方式：通過OAuth2的授權流程

首先第三方網站向授權網站申請第三方授權合作，拿到授權方頒發的client_id和client_secret（一般都是appid+appkey的方式）。

1. 使用者在使用第三方網站時，點選授權按鈕，跳轉到授權方網站，並傳入client_id作為自己的身份識別。
2. 使用者同意授權後，授權網站將頁面跳回第三方網站，並傳給第三方網站Authorization code作為使用者認可的憑證
3. 第三方網站將Authorization code發給自己的伺服器
4. 伺服器將Authorization code和client_secret一併傳送給授權方的伺服器，
5. 通過驗證後，返回access_token。整個OAuth流程結束。

在這就過程中申請的client_secret是伺服器持有的，安全起見不能給客戶端，用服務端去和授權方獲取使用者資訊，再傳給客戶端，包括④，⑤的請求過程也是需要加密的。這才是標準的授權過程。
有了access_token之後，就可以向授權方傳送請求來獲取使用者資訊

例項分析，微博授權

步驟分析就是上面的內容，這裡把第4,6,8請求的引數分析一下
第④步引數：
response_type：指授權型別，必選，這裡填固定值‘code’
client_id：指客戶端id，必選，這裡填在平臺報備時獲取的appid
redirect_uri：指重定向URI，可選
scope：指申請的許可權範圍，可選
state：指客戶端當前狀態，可選，若填了，則認證伺服器會原樣返回該值

第⑥步引數：
grant_type：指使用哪種授權模式，必選，這裡填固定值‘authorization_code’
code：指從第⑤步獲取的code，必選
redirect_uri：指重定向URI，必選，這個值需要和第④步中的redirect_uri保持一致
client_id：指客戶端id，必選，這裡填在平臺報備時獲取的appid
client_secret：指客戶端金鑰，必選，這裡填在平臺報備時獲取的appkey

第⑧步引數：
access_token：指訪問令牌，必選，這裡填第⑦步獲取的access_token
token_type：指令牌型別，必選，大小寫不敏感，bearer型別 / mac型別
expires_in：指過期時間，單位秒，當其他地方已設定過期時間，此處可省略該引數
refresh_token：指更新令牌，可選，用即將過期token換取新token
scope：指許可權範圍，可選，第④步中若已申請過某許可權，此處可省略該引數

Refresh token

我們在上面的第八步中會有refresh_token的引數，這個在實際操作中也比較常見

• 用法：access_token過了有效時間後，呼叫refresh token介面，傳來新的token

自己專案借鑑，簡化OAuth2的過程

有時候我們在自己的專案中，將登陸和授權設計成類似OAuth2的過程，不過去掉Authorization code。登陸成功返回access_token，然後客戶端再請求時，帶上access_token。

2. TCP/IP

我們常常會說到TCP/IP，那到底是什麼呢。這就需要講到網路分層模型。TCP在傳輸層，IP在網路層。那為什麼需要分層？因為網路不穩定，導致需要重傳的問題。為了提高傳輸效率我們就需要分塊，在傳輸層中就會進行分塊。TCP還有兩個重要的內容就是三次握手，四次分手。

三次握手

• 兩次握手是否可以？
  不可以，三次握手防止因網路重傳問題導致無效的連線。比如當A的第一次請求因網路慢B端遲遲收不到的問題，A傳送第二次請求，如果是兩次握手就會建立連線，當網路變好第一次請求再次到達B端就會再次建立一個連線。

四次揮手

• 為什麼連線的時候是三次握手，關閉的時候卻是四次握手？
  因為B端要在收到A端傳送Fin訊息後，可能還有需要傳輸的資料，所以多了一次握手。
• 為什麼A在TIME-WAIT狀態必須等待2MSL的時間？
  當B端收不到A最後發過來的ACK資訊，這時B就會重傳Fin+ACK的訊息，若果馬上關閉就會導致A收不到，而且不會再傳送ACK資訊給B。
  TCP三次握手和四次揮手過程

3. HTTPS建立過程

下圖是HTTPS建立的過程，但是主要步驟都在圖中有顯示

1.客戶端通過傳送Client Hello報文開始SSL通訊。報文中包含客戶端支援的SSL的指定版本、加密元件列表（所使用的加密演算法及金鑰長度），客戶端隨機數，hash演算法。

2.伺服器可進行SSL通訊時，會以Server Hello報文作為應答。和客戶端一樣，在報文中包含SSL版本以及加密元件，服務端隨機數。伺服器的加密元件內容是從接收到客戶端加密元件內篩選出來的。

3.之後伺服器傳送Certificate報文。報文中包含公開金鑰證照。一般實際有三層證照巢狀，其實像下面圖二直接用根證照機構簽名也是可以的，但是一般根證照機構比較忙，需要類似中介的證照機構來幫助。

4.最後伺服器傳送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束。

5.SSL第一次握手結束後，客戶端以Client Key Exchange報文作為回應。報文中包含通訊加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開金鑰進行加密。

6.接著客戶端繼續傳送Change Cipher Spec報文。該報文會提示伺服器，在此報文之後的通訊會採用Pre-master secret金鑰加密。

7.客戶端傳送Finished報文。該報文包含連線至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密報文作為判定標準。

8.伺服器同樣傳送Change Cipher Spec報文。

9.伺服器同樣傳送Finished報文。

10.伺服器和客戶端的Finished報文交換完畢之後，SSL連線就算建立完成。當然，通訊會受到SSL的保護。從此處開始進行應用層協議的通訊，即傳送HTTP響應。

11.應用層協議通訊，即傳送HTTP響應。

12.最後由客戶端斷開連線。斷開連線時，傳送close_notify報文。這步之後再傳送TCP FIN報文來關閉與TCP的通訊。

圖二內容解釋Certificate報文中證照內容。

圖三內容解釋對稱加密的金鑰建立

利用客戶端隨機數，服務端隨機數，per-master secret隨機數生成master secret，再生成客戶端加密金鑰，服務端加密金鑰，客戶端MAC secert，服務端MAC secert。MAC secert用於做報文摘要，這樣能夠查知報文是否遭到篡改，從而保護報文的完整性。

Android網路請求知識（一）HTTP基礎概念
Android網路請求知識（二）對稱和非對稱加密、數字簽名，Hash，Base64編碼
Android網路請求知識（三）授權，TCP/IP，HTTPS建立過程