摘要：所以這個(gè)頁面實(shí)際上是簡(jiǎn)書將用戶導(dǎo)到了，讓和用戶達(dá)成協(xié)議，同意授權(quán)給簡(jiǎn)書。其他人即使竊取了授權(quán)碼，但因?yàn)樗麄兲峁┎涣撕?jiǎn)書的，也會(huì)拒絕授予。

Web安全的問題其實(shí)很有意思，這些在互聯(lián)網(wǎng)上使用的安全協(xié)議看似復(fù)雜，其實(shí)在現(xiàn)實(shí)生活中都有類似的準(zhǔn)則被人們理所當(dāng)然地廣泛使用。比如這里要講的授權(quán)，這是個(gè)所有人都很熟悉的概念。例如你要給張三1000元現(xiàn)金，你手里沒現(xiàn)金，就想讓張三直接去你銀行賬戶里取，那你會(huì)怎么做呢？你可以這樣：

把你的銀行賬號(hào)密碼告訴張三讓他去銀行取錢

但顯然傻瓜才會(huì)這樣干，正確的做法是這樣：

開一張1000元的支票給張三去銀行支取

這張支票就是授權(quán)的憑證，代表你授權(quán)張三從你的銀行賬戶里提取1000元。這樣的事情發(fā)生在互聯(lián)網(wǎng)上，那就是一個(gè)第三方App，想要獲取你在某一網(wǎng)站上的一些私有信息（例如郵箱，名字，照片），需要得到你的授權(quán)。這個(gè)授權(quán)的過程原理和上面的支票類似，當(dāng)然在具體實(shí)現(xiàn)上需要更復(fù)雜更嚴(yán)密的步驟，這就是OAuth協(xié)議做的事情。

有一個(gè)很常見的場(chǎng)景，就是在很多App上，往往可以使用你另一個(gè)平臺(tái)上（微信，QQ等）的賬號(hào)注冊(cè)登錄，例如簡(jiǎn)書:

你可以點(diǎn)擊QQ登錄，它會(huì)給你轉(zhuǎn)到QQ授權(quán)登錄簡(jiǎn)書的界面，從這里開始就進(jìn)入了OAuth 2.0協(xié)議的執(zhí)行流程了。

網(wǎng)上介紹OAuth 2.0協(xié)議的文章也挺多的，所以我們直奔主題，結(jié)合上面的例子，講講使用最廣，最嚴(yán)密的一種實(shí)現(xiàn)方式 - 授權(quán)碼模式。

這里直接貼一張 RFC 6749 里的圖，是整個(gè)授權(quán)碼實(shí)現(xiàn)過程的流程圖。這里有幾個(gè)名詞需要解釋一下：

Resource Owner，就是資源的主人。

User Agent，一般就是瀏覽器。

Client，這里是指第三方App，例如簡(jiǎn)書，注意這里是指它的后臺(tái)而不是前端。

Authorization Server，授權(quán)服務(wù)器，例如QQ的授權(quán)服務(wù)器，它管理用戶QQ信息的授權(quán)。

上面圖中的 ABCDE 五個(gè)步驟：

（A）Client（即第三方App）將用戶導(dǎo)向Authorization Server地址，并且提供一個(gè)重定向URL。
（B）授權(quán)頁面詢問用戶，用戶同意授權(quán)。
（C）Authorization Server產(chǎn)生一個(gè)授權(quán)碼，并且將用戶導(dǎo)向（A）中的重定向URL，帶上授權(quán)碼， 
    作為URL的參數(shù)。
（D）這個(gè)重定向URL實(shí)際上是Client域名下的一個(gè)地址，于是這個(gè)請(qǐng)求發(fā)送到了Client后臺(tái)，它使用
    授權(quán)碼向授權(quán)服務(wù)器申請(qǐng)一個(gè)token。
（E）Client得到token，這個(gè)token就是一個(gè)令牌，可以用來獲取用戶授權(quán)的資源。

咋一看似乎還是難以理解它的具體流程和原理，所以我們還是直接看上面的例子。

在簡(jiǎn)書的登錄界面，點(diǎn)擊QQ圖標(biāo)，就會(huì)被導(dǎo)入到QQ登錄簡(jiǎn)書的授權(quán)界面，即進(jìn)入步驟（A），注意這是一個(gè)QQ域名下的頁面，現(xiàn)在暫時(shí)和簡(jiǎn)書沒有關(guān)系了，對(duì)話只發(fā)生在用戶和QQ之間，我們來看這個(gè)頁面的Http請(qǐng)求：

URI:
https://graph.qq.com/oauth2.0/show?

參數(shù)：
which=Login
display=pc
client_id=100410602
redirect_uri=https://www.jianshu.com/users/auth/qq_connect/callback
response_type=code

這里最重要的參數(shù)是：

client_id，代表了簡(jiǎn)書，是它向QQ授權(quán)服務(wù)器申請(qǐng)的唯一ID。

redirect_uri，這是簡(jiǎn)書域名下的一個(gè)地址，等一會(huì)兒用戶同意授權(quán)后，QQ會(huì)重新將瀏覽器導(dǎo)向這個(gè)地址。

有時(shí)還會(huì)帶一個(gè)參數(shù)scope，這表示授權(quán)的范圍，比如用戶名字，qq號(hào)，好友列表之類的。

所以這個(gè)頁面實(shí)際上是簡(jiǎn)書將用戶導(dǎo)到了QQ，讓QQ和用戶達(dá)成協(xié)議，同意授權(quán)給簡(jiǎn)書。QQ將要求用戶登錄自己的QQ賬號(hào)，驗(yàn)明身份，并向用戶征求相應(yīng)QQ信息的授權(quán)給簡(jiǎn)書。在這里沒有scope參數(shù)，而是QQ讓用戶在頁面上選擇相應(yīng)的授權(quán)范圍，這其實(shí)是一樣的。

用戶在QQ的授權(quán)頁面上用QQ賬號(hào)登錄，并且選擇同意授權(quán)給簡(jiǎn)書相應(yīng)QQ信息。

用戶點(diǎn)擊同意授權(quán)后，QQ將會(huì)生成一個(gè)授權(quán)碼（Authorization Code），并且將用戶導(dǎo)回之前（A）中的redirect_uri，它是這樣的:

URI:
https://www.jianshu.com/users/auth/qq_connect/callback?

附上授權(quán)碼：
code=1EE50EE39E4260EBCFA4892F72F84953

授權(quán)碼實(shí)際上就是用戶同意授權(quán)的憑證，這個(gè)憑證將隨著這個(gè)URL發(fā)回給簡(jiǎn)書。

現(xiàn)在又回到了簡(jiǎn)書的控制范圍，上面的URL由用戶瀏覽器發(fā)到簡(jiǎn)書后，現(xiàn)在開始是簡(jiǎn)書后臺(tái)的工作了。簡(jiǎn)書將使用授權(quán)碼，向QQ申請(qǐng)一個(gè)token令牌，這個(gè)請(qǐng)求是發(fā)生在簡(jiǎn)書后臺(tái)和QQ之間的，具體長(zhǎng)什么樣我們當(dāng)然不得而知，但它至少要包含以下信息：

簡(jiǎn)書的client_id

和這個(gè)client_id對(duì)應(yīng)的secret，這也是簡(jiǎn)書在向QQ申請(qǐng)client_id時(shí)得到的，由簡(jiǎn)書保存，簡(jiǎn)書用它向QQ服務(wù)器證明，這是我本人。

授權(quán)碼

QQ服務(wù)器驗(yàn)證以上信息，向簡(jiǎn)書發(fā)送token，簡(jiǎn)書后面可以用這個(gè)token獲取用戶的相應(yīng)信息。

之后的工作就完全由簡(jiǎn)書決定了，通常的做法是它獲取了用戶QQ信息，然后做一系列處理，比如用用戶的qq號(hào)產(chǎn)生一個(gè)簡(jiǎn)書賬號(hào)（或查找已經(jīng)關(guān)聯(lián)該qq號(hào)的簡(jiǎn)書賬號(hào)），實(shí)現(xiàn)登錄，再將用戶302重定向到簡(jiǎn)書的主頁面。

上面五個(gè)步驟，你來我往似乎很復(fù)雜，我們整理一下實(shí)際上就是兩個(gè)部分：

（A）（B）（C）三步發(fā)生在用戶和QQ之間，當(dāng)然是由簡(jiǎn)書發(fā)起的。簡(jiǎn)書要求QQ向用戶征求授權(quán)，于是QQ和用戶開始對(duì)話，同意授權(quán)，以授權(quán)碼為憑證，這個(gè)授權(quán)碼包含的內(nèi)容是：“用戶xx同意向簡(jiǎn)書提供QQ信息”。就類似于用戶在銀行開出一張支票，支票上寫著“用戶xx同意向張三支付100元”。

然后（D）（E）兩步，轉(zhuǎn)到了簡(jiǎn)書后臺(tái)和QQ之間，QQ重定向用戶瀏覽器到簡(jiǎn)書之前提供的URL，附上那個(gè)授權(quán)碼，類似于你拿到了支票，將支票轉(zhuǎn)發(fā)給了張三。然后簡(jiǎn)書拿著這個(gè)授權(quán)碼，加上能證明自己就是簡(jiǎn)書的相關(guān)證件，也就是簡(jiǎn)書的client_id和secret，向QQ換取一個(gè)token令牌，后面就能用這個(gè)token向QQ取得用戶授權(quán)的相關(guān)信息。

可以看到這里的邏輯是完全符合我們的生活常識(shí)的，正好對(duì)應(yīng)我們向張三開支票取錢的過程，只是步驟上更復(fù)雜更嚴(yán)密，因?yàn)榛ヂ?lián)網(wǎng)的世界有更多風(fēng)險(xiǎn)因素需要考慮。有個(gè)問題大家經(jīng)常會(huì)問到：

為什么要分成兩步，先拿授權(quán)碼，再換取token？如果對(duì)比支票的例子，自始至終支票只有一張，憑票即可兌錢。但是OAuth 2.0協(xié)議卻拆分成了兩步，嚴(yán)格來講授權(quán)碼其實(shí)不是真正的支票，只是支票授權(quán)書，要獲取真正的支票token，需要簡(jiǎn)書親自去向QQ索取。這是因?yàn)锳BC三步發(fā)生在用戶和QQ服務(wù)器之間，這個(gè)對(duì)話信道是不可信任的，可能用戶的瀏覽器已被劫持。所以在這個(gè)信道上不能發(fā)送真正的token，否則token一旦泄露就失去所有安全性了，而只能發(fā)送一個(gè)授權(quán)碼作為憑證，這個(gè)授權(quán)碼是和簡(jiǎn)書綁定的。簡(jiǎn)書拿到這個(gè)憑證之后，再帶上自己的身份證client_id和secret，才能向QQ換取真正的token支票。其他人即使竊取了授權(quán)碼，但因?yàn)樗麄兲峁┎涣撕?jiǎn)書的secret，QQ也會(huì)拒絕授予token。簡(jiǎn)書和QQ之間的對(duì)話是發(fā)生在后臺(tái)的，可以認(rèn)為這個(gè)信道的安全是有保障的。

寫這篇是因?yàn)榭吹角耙魂嘑acebook的數(shù)據(jù)泄漏事件，不過從前因后果來看FB似乎也是被坑了一把，真正的始作俑者是那個(gè)叫Cambridge Analytica的公司，它獲取FB的用戶信息并且分析它們的喜好性格，來有針對(duì)性地向他們推送帶有政治傾向的廣告和宣傳信息來影響選舉。據(jù)說它為了收集用戶數(shù)據(jù)，還在FB的游戲平臺(tái)上發(fā)布小游戲。這種第三方App在用戶玩之前，往往會(huì)告知用戶將收集您的Facebook信息balabala，一般人常常看也不看就點(diǎn)同意了:

這樣的霸王條款其實(shí)我們已經(jīng)很習(xí)慣了，一個(gè)第三方的App，想要獲取你在某些網(wǎng)站上的個(gè)人信息，就要用到Oauth協(xié)議，實(shí)現(xiàn)這種細(xì)粒度的授權(quán)。有些小游戲他要求的授權(quán)范圍就很廣，包括獲取用戶在FB上所有的Post和點(diǎn)贊信息之類的，這其實(shí)就比較危險(xiǎn)了，因?yàn)樗梢苑治瞿愕男睦硇愿瘛＿€有些要求獲取好友列表的，這也值得警惕，因?yàn)槟切?shù)據(jù)收集的公司就是這樣由點(diǎn)到面類似爬蟲一樣獲取大量FB用戶的。FB的事情也是在提醒我們，以后看到這樣的提示信息需要好好考慮一下，因?yàn)橐坏c(diǎn)了同意，就相當(dāng)于你把“支票”開出去了。