国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

對于目前大部分Web應(yīng)用來說，用戶認證基本上都由應(yīng)用自身來完成。具體來說，Web應(yīng)用利用自身存儲的用戶憑證（基本上是用戶名/密碼）與用戶提供的憑證進行比較進而確認其真實身份。但是這種由Web應(yīng)用全權(quán)負責(zé)的認證方式會帶來如下兩個問題：

• 對于用戶來說，他們不得不針對不同的訪問Web應(yīng)用提供不同的用戶憑證。如果這些憑證具有完全不同的密碼，我們沒有多少人能夠記得住，所以對于大部分整天暢游Internet的網(wǎng)友來說，我想他們在不同的網(wǎng)站注冊的賬號都會采用相同的密碼。密碼的共享必然帶來安全隱患，因為我們不能確定Web應(yīng)用本身是否值得信任。“信任危機”來源于兩個方面：首先是對“人品”缺乏信任，我們不知道他們是否具有保護用戶敏感信息的意愿；其次是對“能力”缺乏信任，即我們不清楚他們是否有能力保護用戶的敏感信息，對于知名網(wǎng)站泄露用戶賬號信息的情況我們實在已經(jīng)看的太多了。
• 對于Web應(yīng)用的提供者來說，他們不得不對花費大量的時間、精力和資源來設(shè)計和開發(fā)自己的認證系統(tǒng)。在很多情況下，他們提供的是包含多個子系統(tǒng)的一整套解決方案，如果每個子系統(tǒng)均需要獨立的認證，那么投入的成本可想而知。所以他們希望能夠提供一個單一的“認證中心”來對整個“生態(tài)系統(tǒng)”提供認證，如果這個認證中心完全由第三方來免費提供，這無疑是最好的選擇。

上面提出的這兩點旨在說明一個問題：在Internet環(huán)境下，我們針對具體的Web應(yīng)用設(shè)計獨立的認證系統(tǒng)往往是一件“吃力不討好”的事情。如果我們開發(fā)一個很小的Web應(yīng)用，可能在實現(xiàn)用戶認證功能上面花費的成本比實現(xiàn)應(yīng)用自身業(yè)務(wù)功能的成本更大，而且還會因為“信任危機”導(dǎo)致潛在的使用者不敢注冊。

在這種情況下，如果一個值得信任的第三方能夠提供一種免費的認證服務(wù)，那么這兩個問題均會迎刃而解。實際上目前這樣的第三方認證服務(wù)很多，而且他們的提供者均為值得信賴的IT服務(wù)提供商，比如微軟、Google、Facebook、Twitter，以及國內(nèi)的新浪、騰訊、網(wǎng)易、人人和豆瓣等。就目前來說，這些第三方認證服務(wù)絕大部分均是基于OAuth 2.0設(shè)計的。

假設(shè)我有一件非常重要的文件存儲與于瑞士銀行的私有保險柜中，如果我需要委托某個人將他提取出來，除了將密碼告訴他之外別無他法，但是OAuth的目的卻是定義一種協(xié)議幫助資源的擁有者在不提供自身憑證的前提下授權(quán)第三方應(yīng)用以他的名義存取受保護的資源。OAuth的全稱為“Open Authorization”，所以它是一個開放的協(xié)議，目前最新的版本為2.0。

OAuth 2.0的角色

獲得資源擁有者授權(quán)的第三方應(yīng)用請求受保護的資源采用的不是授權(quán)者的憑證，所有一個被稱為Access Token的安全令牌。Access Token頒發(fā)過程會涉及到若干不同的“實體”，它們在這個過程中扮演者不同的角色，我們通過一個具體的場景來認識一下該過程中涉及到的幾種角色。

假設(shè)我們開發(fā)了一個集成了新浪微博認證的用于發(fā)布打折商品消息的App，經(jīng)過用戶授權(quán)之后它可以調(diào)用新浪微博的Web API或者用戶的電子郵箱地址并發(fā)布相應(yīng)的打折消息。那么OAuth 2.0在這個場景中的作用就在于：用戶授權(quán)該應(yīng)用以自己的名義調(diào)用新浪微博的Web API獲取自己的電子郵箱地址，整個過程涉及到如下4種角色。

• 資源擁有者（RO：Resource Owner）：資源的擁有者也是授權(quán)者，如果它是一個“人”，一般就是指最終用戶。由于“資源”在這個場景中表示為用戶的電子郵箱地址，所以資源擁有者自然就是指最終用戶。
• 客戶端應(yīng)用（Client）：需要取得資源擁有者授權(quán)并最終訪問受保護資源的應(yīng)用，對于我們的場景來說，就是我們創(chuàng)建的App。
• 資源服務(wù)器（Resource Server）：最終承載資源的服務(wù)器，它一般體現(xiàn)為一個可被調(diào)用的Web API。對于我們提供的場景來說，客戶端通過調(diào)用新浪微博得Web API獲得用戶的電子郵箱地址，所以新浪微博就是資源服務(wù)器。
• 授權(quán)服務(wù)器（Authorization Server）：它對用戶（一般情況下為資源擁有者）和客戶端應(yīng)用實施認證，并在用戶授權(quán)的情況下向客戶端應(yīng)用頒發(fā)Access Token。在我們提供的場景中，資源服務(wù)器和認證服務(wù)器合二為一，均為新浪微博。

客戶端憑證

一般來說，如果我們需要針對某種類型的第三方認證服務(wù)來開發(fā)我們自己的應(yīng)用，我們需要向采用的認證服務(wù)提供商對該應(yīng)用進行注冊，注冊成功之后會得到一個唯一標識該應(yīng)用的ClientID和對應(yīng)的ClientSecret（ClientID/ClientSecret是Windows Live Connect 的說法，Twitter和Facebook分別叫做ConsumerKey/ComsumerSecret和AppID/AppSecret。如果采用Google提供的OAuth 2.0 API，ClientID和ClientSecret是不需要的。）。它們相當于客戶端應(yīng)用的憑證，認證服務(wù)利用它們來確定其真實身份。

接下來我們簡單演示一下如何為集成Windows Live Connect API的應(yīng)用注冊一個ClientID。我們利用瀏覽器直接訪問https://account.live.com/developers/applications，如果當前用戶尚未登錄，瀏覽器會自動重定向到登錄窗口。當我們采用某個Windows Live賬號完成登錄之后，如下圖所示的“Windows Live Developer Center”頁面會呈現(xiàn)出來。

然后我們直接點擊“Create application”連接創(chuàng)建一個新的應(yīng)用。我們只需要在顯示頁面的“Application name”文本框中為創(chuàng)建的應(yīng)用設(shè)置一個名稱，同時在“Language”下拉框中選擇適合的語言。如下圖所示，我們?yōu)閯?chuàng)建的應(yīng)用取名為“AppDemo”。

當我們點擊“I accept”按鈕之后，應(yīng)用被成功創(chuàng)建，相應(yīng)的ClientID和ClientSecret也被生成出來。如下圖所示，ClientID和ClientSecret的值分別為“000000004410A2A5”和“HeIrRmGyHHtMqhBDJipfGiauQnSHtYUX”。除此之外，我們要需要設(shè)置重定向地址的域名，Windows Live向客戶端應(yīng)用發(fā)送Access Token，以及其他數(shù)據(jù)采用的URI必須采用此域名，我們在下圖中指定的域名為“https://www.artech.com”。域名成功設(shè)置之后，點擊“Save”按鈕之后整個注冊工作結(jié)束。

處理流程

雖然OAuth 2.0具體采用的執(zhí)行流程因采用不同類型的授權(quán)方式而有所不同，但是整個流程大體上由客戶端應(yīng)用分別與資源擁有者、授權(quán)服務(wù)器和資源服務(wù)器進行的3輪交互來完成。這個過程基本上體現(xiàn)在下圖中，這被稱為經(jīng)典的“Three-Legged OAuth”。

客戶端應(yīng)用試圖獲取某個受保護的資源，首先得取得資源擁有者的授權(quán)，所以第一輪消息交換旨在讓客戶端獲得資源擁有者（即用戶）的授權(quán)?？蛻舳藨?yīng)用得到授權(quán)之后會得到一個被稱為Authorization Grant的對象，該對象實際上就是一個簡單的字符串用以表示成功取得了用戶的授權(quán)。接下來客戶端應(yīng)用利用此Authorization Grant向授權(quán)服務(wù)取獲取用于訪問受保護資源所需的Access Token。在成功獲得Access Token之后，客戶端應(yīng)用將其附加到針對資源服務(wù)器的請求中以獲取它所需要的目標資源。

Authorization Grant

OAuth 2.0的執(zhí)行流程有點類似于的Kerberos認證：客戶端先獲得“認購權(quán)證”TGT（Ticket Granting Ticket），再利用TGT購買“入場券”ST（Service Ticket），最后憑借ST進行服務(wù)調(diào)用。對于OAuth 2.0來說，Access Token相當于Kerberos的ST，而Authorization Grant則與TGT具有相同的作用。

OAuth 2.0中的Authorization Grant代表一種中間憑證（Intermediate Credential），它代表了資源擁有者針對客戶端應(yīng)用獲取目標資源的授權(quán)。OAuth 2.0定義了如下4種Authorization Grant類型，我們也可以利用定義其中的擴展機制定制其他類型的Authorization Grant。Authorization Grant的類型體現(xiàn)了授權(quán)采用的方式以及Access Token的獲取機制。

• Implicit：它代表一種“隱式”授權(quán)方式，即客戶端在取得資源擁有者（最終用戶）授權(quán)的情況下直接獲取Access Token，而不是間接地利用獲取的Authorization Grant來取得Access Token。換句話說，此種類型的Authorization Grant代表根本不需要Authorization Grant，那么上面介紹的“Three-Legged OAuth”變成了“Two-Legged OAuth”。
• Authorization Code：這是最為典型的Authorization Grant，客戶端應(yīng)用在取得資源擁有者授權(quán)之后會從授權(quán)服務(wù)器得到一個Authorization Code作為Authorization Grant。在它獲取寄宿于資源服務(wù)器中的目標資源之前，需要利用此Authorization Code從授權(quán)服務(wù)器獲取Access Token。
• Resource Owner Password Credentials：資源擁有者的憑證直接作為獲取Access Token的Authorization Grant。這種Authorization Grant類型貌似與OAuth設(shè)計的初衷向違背（OAuth的主要目的在于讓客戶端應(yīng)用在不需要提供資源擁有者憑證的情況下能夠以他的名義獲取受保護的資源），但是如果客戶端程序是值得被信任的，用戶（資源擁有者）向其提供自己的憑證也是可以接受的。
• Client Credentials：客戶端應(yīng)用自身的憑證直接作為它用于獲取Access Token的Authorization Grant。這種類型的Authorization Grant適用于客戶端應(yīng)用獲取屬于自己的資源，換句話說客戶端應(yīng)用本身相當于資源的擁有者。

在本系列后續(xù)兩篇文章中我們將對Implicit和Authorization Code這兩種典型的Authorization Grant進行詳細介紹，敬請期待。