• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            WALL E

            Still water run deep...

            OAUTH(摘自wikipedia)

            OAuth
            OAuth的標志

            OAuth(開放授權)是一個開放標準,允許用戶讓第三方網站訪問該用戶在某一網站上存儲的私密的資源(如照片,視頻,聯系人列表),而無需將用戶名和密碼提供給第三方網站。

            OAuth允許用戶提供一個令牌,而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每一個令牌授權一個特定的網站(例如,視頻編輯網站)在特定的時段(例如,接下來的2小時內)內訪問特定的資源(例如僅僅是某一相冊中的視頻)。這樣,OAuth允許用戶授權第三方網站訪問他們存儲在另外的服務提供者上的信息,而不需要分享他們的訪問許可或他們數據的所有內容。

            OAuth是OpenID的一個補充,但是完全不同的服務。

            目錄

            認證和授權過程

            在認證和授權的過程中涉及的三方包括:

            • 服務提供方,用戶使用服務提供方來存儲受保護的資源,如照片,視頻,聯系人列表。
            • 用戶,存放在服務提供方的受保護的資源的擁有者。
            • 客戶端,要訪問服務提供方資源的第三方應用,通常是網站,如提供照片打印服務的網站。在認證過程之前,客戶端要向服務提供者申請客戶端標識。

            使用OAuth進行認證和授權的過程如下所示:

            1. 用戶訪問客戶端的網站,想操作用戶存放在服務提供方的資源。
            2. 客戶端服務提供方請求一個臨時令牌。
            3. 服務提供方驗證客戶端的身份后,授予一個臨時令牌。
            4. 客戶端獲得臨時令牌后,將用戶引導至服務提供方的授權頁面請求用戶授權。在這個過程中將臨時令牌和客戶端的回調連接發送給服務提供方
            5. 用戶服務提供方的網頁上輸入用戶名和密碼,然后授權該客戶端訪問所請求的資源。
            6. 授權成功后,服務提供方引導用戶返回客戶端的網頁。
            7. 客戶端根據臨時令牌從服務提供方那里獲取訪問令牌。
            8. 服務提供方根據臨時令牌和用戶的授權情況授予客戶端訪問令牌。
            9. 客戶端使用獲取的訪問令牌訪問存放在服務提供方上的受保護的資源。

            歷史

            OAuth開始于2006年11月,當時布萊恩·庫克Blaine Cook)正在開發TwitterOpenID實現。與此同時,Ma.gnolia需要一個解決方案允許使用OpenID的成員授權Dashboard訪問他們的服務。這樣庫克、克里斯·梅西納Chris Messina)和來自Ma.gnolia的拉里·哈爾夫(Larry Halff)與戴維·雷科爾頓(David Recordon)會面討論在Twitter和Ma.gnolia API上使用OpenID進行委托授權。 他們討論得出沒有開發標準完成API訪問的委托。

            2007年4月,成立了OAuth討論組,這個由實現者組成的小組撰寫了一個開放協議的提議草案。來自Google德維特·克林頓(DeWitt Clinton)獲悉OAuth項目后,表示他有興趣支持這個工作。2007年7月,團隊起草了最初的規范。隨后,Eran Hammer-Lahav加入團隊并協調了許多OAuth的稿件,創建了更為正式的規范。2007年10月3日, OAuth核心 1.0最后的草案發布了。

            2008年11月,在明尼阿波利斯舉行的互聯網工程任務組第73次會議上, 舉行了OAuth的BoF[1]討論將該協議納入IETF做進一步的規范化工作。 這個會議參加的人很多,關于正式地授權在IETF設立一個OAuth工作組這一議題得到了廣泛的支持。

            2010年4月,OAuth 1.0協議發表為RFC 5849,一個非正式RFC

            OAuth 2.0

            OAuth 2.0是OAuth協議的下一版本,但不向后兼容OAuth 1.0。 OAuth 2.0關注客戶端開發者的簡易性,同時為Web應用,桌面應用和手機,和起居室設備提供專門的認證流程。規范還在IETF OAuth工作組的開發中[2] ,按照Eran Hammer-Lahav的說法,OAuth將于2010年末完成[3]

            Facebook的新的Graph API只支持OAuth 2.0[4],Google在2011年3月亦宣布Google API對OAuth 2.0的支援[5]

            安全

            2009年4月23日,OAuth宣告了一個1.0協議的安全漏洞。該漏洞影響了OAuth 1.0核心規范第6節的OAuth的認證流程(也稱作3階段OAuth) [6] 于是,發布了OAuth Core協議1.0a版本來解決這一問題。[7]

            參見

            參考文獻

            外部鏈接

            posted on 2011-04-23 23:46 -葉子- 閱讀(346) 評論(0)  編輯 收藏 引用 所屬分類: 網絡技術

            <2011年4月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            1234567

            導航

            統計

            公告

            is coming...

            常用鏈接

            留言簿

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            相冊

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            国产成人久久久精品二区三区| 国产精品久久自在自线观看| 亚洲精品无码专区久久同性男| 久久伊人五月天论坛| 思思久久99热只有频精品66| 国产成人精品综合久久久| 久久久久人妻精品一区| 国内精品久久久久久久涩爱 | 午夜精品久久久久久中宇| 精品国产乱码久久久久久郑州公司 | 无码任你躁久久久久久老妇App| 亚洲精品乱码久久久久久不卡| 国色天香久久久久久久小说 | 潮喷大喷水系列无码久久精品| 久久久99精品成人片中文字幕| 亚洲级αV无码毛片久久精品 | 囯产精品久久久久久久久蜜桃 | 热re99久久6国产精品免费| 国产精品成人99久久久久| 久久天天躁狠狠躁夜夜躁2O2O| 色99久久久久高潮综合影院| 91视频国产91久久久| 午夜精品久久久久久毛片| 久久这里的只有是精品23| 久久国产高清一区二区三区| 国产精品美女久久久久| 日产精品久久久久久久性色| 亚洲国产成人久久综合一区77 | 久久精品国产亚洲一区二区| 成人综合久久精品色婷婷| 国产伊人久久| 久久伊人色| 亚洲午夜福利精品久久| 亚洲国产精品成人久久蜜臀 | 精品一二三区久久aaa片| 伊人色综合久久天天人守人婷| 久久AⅤ人妻少妇嫩草影院| 亚洲综合久久综合激情久久| 99久久精品国产免看国产一区| 久久精品夜夜夜夜夜久久| 人妻久久久一区二区三区|