資訊專欄INFORMATION COLUMN
摘要：使用時不應該通過傳遞使用時不應該通過傳遞根據安全最佳實踐章節在使用時您不應該把放到中第一瀏覽器地址欄本來就是暴露的第二可以查看瀏覽記錄，找到。
OAuth 2.1 是 OAuth 2.0 的下一個版本, OAuth 2.1 根據最佳安全實踐(BCP), 目前是第18個版本，對 OAuth 2.0 協議進行整合和精簡, 移除不安全的授權流程, 并發布了 OAuth 2.1 規范草案, 下面列出了和 OAuth 2.0 相比的主要區別。
根據 OAuth 2.0 安全最佳實踐(Security Best Current Practices) 2.1.1 章節
授權碼 (Authorization Code) 模式大家都很熟悉了,也是最安全的授權流程, 那 PKCE 又是什么呢? PKCE 全稱是 Proof Key for Code Exchange, 在 2015 年發布為 RFC 7636, 我們知道, 授權碼模式雖好, 但是它不能給公開的客戶端用, 因為公開的客戶端沒有能力保存好秘鑰(client_secret), 所以在此之前, 對于公開的客戶端, 只能使用隱式模式和密碼模式, PKCE 就是為了解決這個問題而出現的, 另外它也可以防范授權碼攔截攻擊, 實際上它的原理是客戶端提供一個自創建的證明給授權服務器， 授權服務器通過它來驗證客戶端，把訪問令牌(access_token) 頒發給真實的客戶端而不是偽造的，下邊是 Authorization Code + PKCE 的授權流程圖。
根據 OAuth 2.0 安全最佳實踐(Security Best Current Practices) 2.1.2 章節
在 OAuth 2.1 規范草案中, 授權模式中已經找不到隱式授權(Implicit Grant), 我們知道, 隱式授權是 OAuth 2.0 中的授權模式, 是授權碼模式的簡化版本, 用戶同意授權后, 直接就能返回訪問令牌 access_token, 同時這種也是不安全的。
現在您可以考慮替換為 Authorization Code + PKCE 的授權模式。
根據 OAuth 2.0 安全最佳實踐(Security Best Current Practices) 2.4 章節
在 OAuth 2.1 規范草案中, 密碼授權也被移除, 實際上這種授權模式在 OAuth 2.0中都是不推薦使用的, 密碼授權的流程是, 用戶把賬號密碼告訴客戶端, 然后客戶端再去申請訪問令牌, 這種模式只在用戶和客戶端高度信任的情況下才使用。
試想一下, 在你手機上有一個網易云音樂的APP, 現在要使用qq賬號登錄, 這時網易云音樂說, 你把qq賬號密碼告訴我就行了, 我拿著你的賬號密碼去QQ那邊登錄, 這就很離譜了!
正確的做法是, 用戶在網易云音樂要使用qq登錄, 如果用戶也安裝了qq 的客戶端, 應該喚起qq應用, 在qq頁面完成授權操作, 然后返回到網易云音樂。如果用戶沒有安裝qq客戶端應用, 喚起瀏覽器, 引導用戶去qq的授權頁面, 用戶授權完成后, 返回到網易云音樂。
請注意, OAuth 是專門為委托授權而設計的，為了讓第三方應用使用授權, 它不是為身份驗證而設計的, 而 OpenID Connect（建立在 OAuth 之上）是專為身份驗證而設計, 所以, 在使用 OAuth 授權協議時, 你需要知道你使用的客戶端是第三方應用程序還是第一方應用，這很重要！因為 OAuth 2.1 已經不支持第一方應用授權！
現在您可以考慮使用 Authorization Code + PKCE 替換之前的密碼授權模式。
根據 OAuth 2.0 安全最佳實踐(Security Best Current Practices) 4.3.2 章節
在使用 access_token 時, 您不應該把token放到URL中, 第一, 瀏覽器地址欄本來就是暴露的, 第二, 可以查看瀏覽記錄，找到 access_token。
正確的做法是, 把 access_token 放到 Http header 或者是 POST body 中。
根據 OAuth 2.0 安全最佳實踐(Security Best Current Practices) 4.13.2 章節
access_token 訪問令牌, refresh_token 刷新令牌, 刷新令牌可以在一段時間內獲取訪問令牌, 平衡了用戶體驗和安全性, 在 OAuth 2.1 中, refresh_token 應該是一次性的, 用過后失效, 使用 refresh_token 獲取access_token時, 還可以返回一個新的 refresh_token。
根據 OAuth 2.0 安全最佳實踐(Security Best Current Practices) 4.1.3 章節
在 OAuth 2.0 的授權碼流程中, 需要設置一個回調地址 redirect_uri, 如下
https://www.authorization-server.com/oauth2/authorize?response_type=code&client_id=s6BhdRkqt3&scope=user&state=8b815ab1d177f5c8e &redirect_uri=https://www.client.com/callback假如有三個不同的客戶端
這時可能會使用一個通配符的 redirect_uri, 比如 *.client.com, 這樣會有什么風險呢? 實際上, 惡意程序有機會篡改 redirect_uri, 假設惡意程序的域名是 https://attacker.com, 然后把 redirect_uri 改成 https://attacker.com/.client.com, 這樣授權碼就發送給了惡意程序。
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04
OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics-18
https://fusionauth.io/learn/expert-advice/oauth/differences-between-oauth-2-oauth-2-1
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/124820.html
摘要：總結總結歸根結底并不是要推翻，而是根據其安全最佳實踐移除不安全的授權流程并且對擴展協議進行整合讓原本復雜如迷宮的規范成為更易用，更安全的授權規范。背景2010年, OAuth 授權規范 1.0 (rfc 5849) 版本發布, 2年后, 更簡單易用的 OAuth 2.0 規范發布（rfc 6749）, 這也是大家最熟悉并且在互聯網上使用最廣泛的版本, 在2012年的時候, iPhone 5 ...
摘要：結構概述版本協議中文文檔。根據已配置的認證器元數據驗證認證器的可靠性，確保只有可信賴的認證器注冊使用。利用認證機構提供的認證元數據來對認證器的真實性和可靠性進行驗證。具體來說，是通過認證器元數據中發布的認證公鑰完成驗證。 FIDO UAF 結構概述 版本 v1.1 FIDO UAF協議中文文檔。 現在FIDO UAF有關的文章還比較少，這主要是文檔翻譯和UAF系統概要介紹。 FIDO...
摘要：安全機制的設計現在，大部分的接口都采用架構，最重要的一個設計原則就是，客戶端與服務器的交互在請求之間是無狀態的，也就是說，當涉及到用戶狀態時，每次請求都要帶上身份驗證信息。 App與服務器的通信接口如何設計得好，需要考慮的地方挺多的，在此根據我的一些經驗做一些總結分享，旨在拋磚引玉。 安全機制的設計 現在，大部分App的接口都采用RESTful架構，RESTFul最重要的一個設計原則就...
摘要：這樣，讓用戶可以授權第三方網站訪問他們存儲在另外服務提供者的某些特定信息，而非所有內容。 不久之前 Dearmadman 曾寫過一篇 使用 Laravel Socialite 集成微信登錄 的文章，但是似乎還是有些同學不太明白，詢問著如何集成 QQ 登錄，那么，本篇我們就來剖析一下 Laravel Socialite 的詳細內容。讓各位同學都獲得 Laravel Socialite 所...
閱讀 2793·2021-11-24 09:39
閱讀 2552·2021-11-23 09:51
閱讀 1835·2021-11-17 09:33
閱讀 1744·2021-10-22 09:54
閱讀 1876·2021-08-16 11:00
閱讀 3427·2019-08-30 15:53
閱讀 1735·2019-08-30 13:19
閱讀 2907·2019-08-30 12:49
