• <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 -葉子- 閱讀(342) 評論(0)  編輯 收藏 引用 所屬分類: 網絡技術

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導航

            統計

            公告

            is coming...

            常用鏈接

            留言簿

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            相冊

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            午夜精品久久久久久影视777| 99久久99久久| 一级女性全黄久久生活片免费 | 99久久99这里只有免费的精品| 久久99亚洲网美利坚合众国| 国产精品久久免费| 国产精品成人久久久久久久| 人人狠狠综合久久亚洲| 伊人久久大香线蕉AV色婷婷色| 亚洲国产精品人久久| 欧美国产成人久久精品| 国产成人精品久久二区二区| 欧美国产精品久久高清| 久久综合久久久| 久久久久久久97| 久久久99精品一区二区| 国产亚洲精久久久久久无码 | 亚洲欧洲久久久精品| 精品久久久久久无码专区 | 91精品婷婷国产综合久久| 久久青青色综合| 久久亚洲精品无码观看不卡| 97久久国产亚洲精品超碰热 | 欧美亚洲色综久久精品国产| 久久精品国产WWW456C0M| 精品一区二区久久| 天天爽天天狠久久久综合麻豆| 亚洲国产日韩欧美久久| 久久国产精品一区| 久久九九亚洲精品| 国产亚洲婷婷香蕉久久精品| 人妻精品久久久久中文字幕69 | 久久久久久国产a免费观看不卡| 久久99国产精品成人欧美| 久久久一本精品99久久精品66 | 国产精品99久久久久久董美香| 久久综合给合久久狠狠狠97色| 欧美精品国产综合久久| 久久综合鬼色88久久精品综合自在自线噜噜 | 久久无码AV一区二区三区| 久久天天躁狠狠躁夜夜2020|