摘要:所以這個頁面實際上是簡書將用戶導到了,讓和用戶達成協(xié)議,同意授權(quán)給簡書。其他人即使竊取了授權(quán)碼,但因為他們提供不了簡書的,也會拒絕授予。
Web安全的問題其實很有意思,這些在互聯(lián)網(wǎng)上使用的安全協(xié)議看似復雜,其實在現(xiàn)實生活中都有類似的準則被人們理所當然地廣泛使用。比如這里要講的授權(quán),這是個所有人都很熟悉的概念。例如你要給張三1000元現(xiàn)金,你手里沒現(xiàn)金,就想讓張三直接去你銀行賬戶里取,那你會怎么做呢?你可以這樣:
把你的銀行賬號密碼告訴張三讓他去銀行取錢
但顯然傻瓜才會這樣干,正確的做法是這樣:
開一張1000元的支票給張三去銀行支取
這張支票就是授權(quán)的憑證,代表你授權(quán)張三從你的銀行賬戶里提取1000元。這樣的事情發(fā)生在互聯(lián)網(wǎng)上,那就是一個第三方App,想要獲取你在某一網(wǎng)站上的一些私有信息(例如郵箱,名字,照片),需要得到你的授權(quán)。這個授權(quán)的過程原理和上面的支票類似,當然在具體實現(xiàn)上需要更復雜更嚴密的步驟,這就是OAuth協(xié)議做的事情。
有一個很常見的場景,就是在很多App上,往往可以使用你另一個平臺上(微信,QQ等)的賬號注冊登錄,例如簡書:
你可以點擊QQ登錄,它會給你轉(zhuǎn)到QQ授權(quán)登錄簡書的界面,從這里開始就進入了OAuth 2.0協(xié)議的執(zhí)行流程了。
OAuth 2.0 協(xié)議 - 授權(quán)碼模式網(wǎng)上介紹OAuth 2.0協(xié)議的文章也挺多的,所以我們直奔主題,結(jié)合上面的例子,講講使用最廣,最嚴密的一種實現(xiàn)方式 - 授權(quán)碼模式。
這里直接貼一張 RFC 6749 里的圖,是整個授權(quán)碼實現(xiàn)過程的流程圖。這里有幾個名詞需要解釋一下:
Resource Owner,就是資源的主人。
User Agent,一般就是瀏覽器。
Client,這里是指第三方App,例如簡書,注意這里是指它的后臺而不是前端。
Authorization Server,授權(quán)服務(wù)器,例如QQ的授權(quán)服務(wù)器,它管理用戶QQ信息的授權(quán)。
上面圖中的 ABCDE 五個步驟:
(A)Client(即第三方App)將用戶導向Authorization Server地址,并且提供一個重定向URL。 (B)授權(quán)頁面詢問用戶,用戶同意授權(quán)。 (C)Authorization Server產(chǎn)生一個授權(quán)碼,并且將用戶導向(A)中的重定向URL,帶上授權(quán)碼, 作為URL的參數(shù)。 (D)這個重定向URL實際上是Client域名下的一個地址,于是這個請求發(fā)送到了Client后臺,它使用 授權(quán)碼向授權(quán)服務(wù)器申請一個token。 (E)Client得到token,這個token就是一個令牌,可以用來獲取用戶授權(quán)的資源。
咋一看似乎還是難以理解它的具體流程和原理,所以我們還是直接看上面的例子。
步驟(A)在簡書的登錄界面,點擊QQ圖標,就會被導入到QQ登錄簡書的授權(quán)界面,即進入步驟(A),注意這是一個QQ域名下的頁面,現(xiàn)在暫時和簡書沒有關(guān)系了,對話只發(fā)生在用戶和QQ之間,我們來看這個頁面的Http請求:
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,代表了簡書,是它向QQ授權(quán)服務(wù)器申請的唯一ID。
redirect_uri,這是簡書域名下的一個地址,等一會兒用戶同意授權(quán)后,QQ會重新將瀏覽器導向這個地址。
有時還會帶一個參數(shù)scope,這表示授權(quán)的范圍,比如用戶名字,qq號,好友列表之類的。
所以這個頁面實際上是簡書將用戶導到了QQ,讓QQ和用戶達成協(xié)議,同意授權(quán)給簡書。QQ將要求用戶登錄自己的QQ賬號,驗明身份,并向用戶征求相應(yīng)QQ信息的授權(quán)給簡書。在這里沒有scope參數(shù),而是QQ讓用戶在頁面上選擇相應(yīng)的授權(quán)范圍,這其實是一樣的。
步驟(B)用戶在QQ的授權(quán)頁面上用QQ賬號登錄,并且選擇同意授權(quán)給簡書相應(yīng)QQ信息。
步驟(C)用戶點擊同意授權(quán)后,QQ將會生成一個授權(quán)碼(Authorization Code),并且將用戶導回之前(A)中的redirect_uri,它是這樣的:
URI: https://www.jianshu.com/users/auth/qq_connect/callback? 附上授權(quán)碼: code=1EE50EE39E4260EBCFA4892F72F84953
授權(quán)碼實際上就是用戶同意授權(quán)的憑證,這個憑證將隨著這個URL發(fā)回給簡書。
步驟(D)現(xiàn)在又回到了簡書的控制范圍,上面的URL由用戶瀏覽器發(fā)到簡書后,現(xiàn)在開始是簡書后臺的工作了。簡書將使用授權(quán)碼,向QQ申請一個token令牌,這個請求是發(fā)生在簡書后臺和QQ之間的,具體長什么樣我們當然不得而知,但它至少要包含以下信息:
簡書的client_id
和這個client_id對應(yīng)的secret,這也是簡書在向QQ申請client_id時得到的,由簡書保存,簡書用它向QQ服務(wù)器證明,這是我本人。
授權(quán)碼
步驟(E)QQ服務(wù)器驗證以上信息,向簡書發(fā)送token,簡書后面可以用這個token獲取用戶的相應(yīng)信息。
之后的工作就完全由簡書決定了,通常的做法是它獲取了用戶QQ信息,然后做一系列處理,比如用用戶的qq號產(chǎn)生一個簡書賬號(或查找已經(jīng)關(guān)聯(lián)該qq號的簡書賬號),實現(xiàn)登錄,再將用戶302重定向到簡書的主頁面。
原理分析上面五個步驟,你來我往似乎很復雜,我們整理一下實際上就是兩個部分:
(A)(B)(C)三步發(fā)生在用戶和QQ之間,當然是由簡書發(fā)起的。簡書要求QQ向用戶征求授權(quán),于是QQ和用戶開始對話,同意授權(quán),以授權(quán)碼為憑證,這個授權(quán)碼包含的內(nèi)容是:“用戶xx同意向簡書提供QQ信息”。就類似于用戶在銀行開出一張支票,支票上寫著“用戶xx同意向張三支付100元”。
然后(D)(E)兩步,轉(zhuǎn)到了簡書后臺和QQ之間,QQ重定向用戶瀏覽器到簡書之前提供的URL,附上那個授權(quán)碼,類似于你拿到了支票,將支票轉(zhuǎn)發(fā)給了張三。然后簡書拿著這個授權(quán)碼,加上能證明自己就是簡書的相關(guān)證件,也就是簡書的client_id和secret,向QQ換取一個token令牌,后面就能用這個token向QQ取得用戶授權(quán)的相關(guān)信息。
可以看到這里的邏輯是完全符合我們的生活常識的,正好對應(yīng)我們向張三開支票取錢的過程,只是步驟上更復雜更嚴密,因為互聯(lián)網(wǎng)的世界有更多風險因素需要考慮。有個問題大家經(jīng)常會問到:
為什么要分成兩步,先拿授權(quán)碼,再換取token?如果對比支票的例子,自始至終支票只有一張,憑票即可兌錢。但是OAuth 2.0協(xié)議卻拆分成了兩步,嚴格來講授權(quán)碼其實不是真正的支票,只是支票授權(quán)書,要獲取真正的支票token,需要簡書親自去向QQ索取。這是因為ABC三步發(fā)生在用戶和QQ服務(wù)器之間,這個對話信道是不可信任的,可能用戶的瀏覽器已被劫持。所以在這個信道上不能發(fā)送真正的token,否則token一旦泄露就失去所有安全性了,而只能發(fā)送一個授權(quán)碼作為憑證,這個授權(quán)碼是和簡書綁定的。簡書拿到這個憑證之后,再帶上自己的身份證client_id和secret,才能向QQ換取真正的token支票。其他人即使竊取了授權(quán)碼,但因為他們提供不了簡書的secret,QQ也會拒絕授予token。簡書和QQ之間的對話是發(fā)生在后臺的,可以認為這個信道的安全是有保障的。
后記寫這篇是因為看到前一陣Facebook的數(shù)據(jù)泄漏事件,不過從前因后果來看FB似乎也是被坑了一把,真正的始作俑者是那個叫Cambridge Analytica的公司,它獲取FB的用戶信息并且分析它們的喜好性格,來有針對性地向他們推送帶有政治傾向的廣告和宣傳信息來影響選舉。據(jù)說它為了收集用戶數(shù)據(jù),還在FB的游戲平臺上發(fā)布小游戲。這種第三方App在用戶玩之前,往往會告知用戶將收集您的Facebook信息balabala,一般人常??匆膊豢淳忘c同意了:
這樣的霸王條款其實我們已經(jīng)很習慣了,一個第三方的App,想要獲取你在某些網(wǎng)站上的個人信息,就要用到Oauth協(xié)議,實現(xiàn)這種細粒度的授權(quán)。有些小游戲他要求的授權(quán)范圍就很廣,包括獲取用戶在FB上所有的Post和點贊信息之類的,這其實就比較危險了,因為他可以分析你的心理性格。還有些要求獲取好友列表的,這也值得警惕,因為那些數(shù)據(jù)收集的公司就是這樣由點到面類似爬蟲一樣獲取大量FB用戶的。FB的事情也是在提醒我們,以后看到這樣的提示信息需要好好考慮一下,因為一旦點了同意,就相當于你把“支票”開出去了。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/11381.html
摘要:地址每次面試多多少少都會被問到等等之類協(xié)議,協(xié)議相關(guān)的問題也可以說是面試必備,所以我把這些知識單獨收集成了一篇文章。即標志位和標志位均為。發(fā)送完畢后,服務(wù)器端進入狀態(tài)。認證服務(wù)器對客戶端進行認證以后,確認無誤,同意發(fā)放令牌。 Git 地址:https://github.com/todayqq/PH... 每次面試多多少少都會被問到 HTTP、HTTPS、TCP、Socket、 OAu...
摘要:總結(jié)總結(jié)歸根結(jié)底并不是要推翻,而是根據(jù)其安全最佳實踐移除不安全的授權(quán)流程并且對擴展協(xié)議進行整合讓原本復雜如迷宮的規(guī)范成為更易用,更安全的授權(quán)規(guī)范。背景2010年, OAuth 授權(quán)規(guī)范 1.0 (rfc 5849) 版本發(fā)布, 2年后, 更簡單易用的 OAuth 2.0 規(guī)范發(fā)布(rfc 6749), 這也是大家最熟悉并且在互聯(lián)網(wǎng)上使用最廣泛的版本, 在2012年的時候, iPhone 5 ...
摘要:訪問令牌表示授權(quán)授予授予的范圍持續(xù)時間和其他屬性。該規(guī)范還定義了一組通用客戶端元數(shù)據(jù)字段和值,供客戶端在注冊期間使用。授權(quán)服務(wù)器可以為客戶端元數(shù)據(jù)中遺漏的任何項提供默認值。 以前的開發(fā)模式是以MVC為主,但是隨著互聯(lián)網(wǎng)行業(yè)快速的發(fā)展逐漸的演變成了前后端分離,若項目中需要做登錄的話,那么token成為前后端唯一的一個憑證。 token即標志、記號的意思,在IT領(lǐng)域也叫作令牌。在計算機身份...
摘要:使用時不應(yīng)該通過傳遞使用時不應(yīng)該通過傳遞根據(jù)安全最佳實踐章節(jié)在使用時您不應(yīng)該把放到中第一瀏覽器地址欄本來就是暴露的第二可以查看瀏覽記錄,找到。OAuth 2.1 是 OAuth 2.0 的下一個版本, OAuth 2.1 根據(jù)最佳安全實踐(BCP), 目前是第18個版本,對 OAuth 2.0 協(xié)議進行整合和精簡, 移除不安全的授權(quán)流程, 并發(fā)布了 OAuth 2.1 規(guī)范草案, 下面列出了...
摘要:阮一峰老師曾經(jīng)在他的博文理解里對這個概念有了深入淺出的闡述。注這是阮一峰老師文章里提到的中的認證模式之一簡化模式客戶聽起來不錯這樣我就不需要把我們公司的用戶的密碼提供給您了。這下您放心了吧注這種方式即阮一峰文章里介紹的授權(quán)碼模式。 阮一峰老師曾經(jīng)在他的博文理解OAuth 2.0里對這個概念有了深入淺出的闡述。 http://www.ruanyifeng.com/blo... 本文會結(jié)合...
閱讀 2910·2023-04-26 02:14
閱讀 3760·2019-08-30 15:55
閱讀 1847·2019-08-29 16:42
閱讀 2762·2019-08-26 11:55
閱讀 2851·2019-08-23 13:38
閱讀 489·2019-08-23 12:10
閱讀 1317·2019-08-23 11:44
閱讀 2807·2019-08-23 11:43