OAuth 2.0以及它的工作過程工作過程

gongchengship發表於2024-10-21
OAuth

這裡可以看阮一峰老師關於 OAuth 2.0 的介紹：
理解OAuth 2.0：https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
OAuth 2.0 的一個簡單解釋： https://www.ruanyifeng.com/blog/2019/04/oauth_design.html
OAuth 2.0 的四種方式：https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

OAuth 2.0 是一種用於訪問授權的開放標準協議，它允許應用程式在無需暴露使用者憑據（如使用者名稱和密碼）的情況下安全地訪問其他應用程式的資源。OAuth 2.0 的設計目標是解決跨平臺或跨應用之間的授權問題，它允許第三方應用程式代表使用者訪問資源，而無需直接向第三方暴露使用者的密碼。

一、OAuth 2.0 的背景與問題

在現代網路應用中，使用者常常需要授權第三方應用程式訪問自己在某些服務提供商（如Google、Facebook等）上的資源。例如，一個使用者希望授權某個社交媒體應用程式訪問他在Google Drive上的照片，而不希望將自己的Google賬戶密碼交給這個社交媒體應用程式。在這種情況下，傳統的憑據分享方式存在嚴重的安全風險：

  1. 憑據共享風險：使用者需要將自己的使用者名稱和密碼提供給第三方，這增加了密碼被濫用或洩露的風險。
  2. 許可權過度：一旦使用者共享了自己的憑據，第三方可以獲得對使用者所有資源的訪問許可權，超出使用者的預期。
  3. 憑據無法撤銷：如果使用者想要撤銷對某個應用的授權，他不得不更改自己的密碼，從而影響其他已授權的服務。

為了解決這些問題，OAuth 2.0 引入了一種安全、可靠且靈活的方式來管理授權和訪問。

二、OAuth 2.0 解決了什麼問題？

  1. 分離身份驗證與授權：OAuth 2.0 允許第三方應用程式（也稱為客戶端應用）在使用者授權的情況下訪問資源，而無需直接獲取使用者的憑據。

  2. 精細化許可權控制：透過OAuth 2.0，使用者可以授權應用程式訪問特定的資源或執行特定的操作，而無需開放所有許可權。

  3. 可撤銷性：使用者可以隨時透過資源提供商（如Google）的設定介面撤銷某個應用程式的授權，而無需更改密碼。

  4. 減少使用者密碼暴露的風險：應用程式不再直接處理使用者的密碼，授權流程透過訪問令牌控制，確保使用者憑據的安全。

三、OAuth 2.0 的角色

在OAuth 2.0的架構中，主要涉及四個角色：

  1. 資源所有者（Resource Owner）：通常是使用者，擁有需要訪問的資源。例如，使用者的Google Drive上的檔案。

  2. 客戶端（Client）：請求訪問資源的應用程式。它可以是一個Web應用、移動應用或桌面應用。

  3. 授權伺服器（Authorization Server）：負責認證資源所有者的身份，並在獲得授權後，頒發訪問令牌（Access Token）。授權伺服器通常由資源伺服器同一實體管理（例如，Google 的授權伺服器可以為Google Drive的資源提供授權）。

  4. 資源伺服器（Resource Server）：提供保護資源的伺服器，例如Google Drive。資源伺服器透過驗證訪問令牌來確定客戶端是否有許可權訪問資源。

四、OAuth 2.0 的工作流程

OAuth 2.0 的授權流程分為幾個步驟，涉及令牌（Token）交換等關鍵過程。它可以透過多種授權方式完成，其中最常用的是授權碼授權（Authorization Code Grant）流程。下面是OAuth 2.0的完整工作過程：

1. 資源所有者向客戶端發起操作

使用者（資源所有者）在客戶端應用中進行某項操作，該操作需要訪問資源伺服器上的資源。客戶端會跳轉至授權伺服器的認證頁面，讓使用者授權。

2. 客戶端向授權伺服器請求授權

客戶端將使用者重定向到授權伺服器的授權頁面，URL中通常包含以下資訊：

  • client_id：客戶端應用的唯一識別符號。
  • redirect_uri：授權成功後重定向的地址（客戶端提供）。
  • response_type：通常為 code，表示客戶端期望獲取授權碼。
  • scope：請求訪問的資源範圍（如讀取郵件、訪問檔案等）。
  • state：用於防止CSRF攻擊的隨機字串。

示例授權請求：

GET /authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=code&scope=email&state=STATE

3. 使用者認證與授權

資源所有者會被授權伺服器（如Google的OAuth頁面）要求進行身份驗證（如果尚未登入）。登入後，授權伺服器會向使用者展示授權頁面，使用者可以選擇是否授權客戶端訪問指定的資源範圍（scope）。

4. 授權伺服器返回授權碼

如果使用者同意授權，授權伺服器會生成一個臨時的授權碼（Authorization Code），並將其透過redirect_uri重定向到客戶端。返回的URL中包含以下資訊：

  • code：授權碼，客戶端可以用它換取訪問令牌。
  • state：與最初請求中的 state 值匹配，以防止CSRF攻擊。

示例返回：

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=AUTHORIZATION_CODE&state=STATE

5. 客戶端使用授權碼向授權伺服器請求訪問令牌

客戶端收到授權碼後，會向授權伺服器的令牌端點（Token Endpoint）發出POST請求，換取訪問令牌（Access Token）。該請求通常包含以下引數：

  • grant_type：授權型別，authorization_code 表示使用授權碼模式。
  • code：步驟4中獲得的授權碼。
  • redirect_uri：與前面授權請求中使用的 redirect_uri 一致。
  • client_id 和 client_secret：客戶端的識別符號和金鑰，用於證明客戶端的身份。

示例POST請求：

POST /token
Host: https://authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

6. 授權伺服器返回訪問令牌

授權伺服器驗證授權碼和客戶端身份後，會返回一個訪問令牌（Access Token），有時還會返回一個重新整理令牌（Refresh Token），用於獲取新的訪問令牌。

示例返回：

{
  "access_token": "ACCESS_TOKEN",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "REFRESH_TOKEN"
}
  • access_token：用於訪問資源伺服器的憑證。
  • expires_in：令牌有效期（秒）。
  • refresh_token：用於獲取新的訪問令牌，無需使用者再次授權。

7. 客戶端使用訪問令牌訪問資源

客戶端持有訪問令牌後，可以透過請求資源伺服器的API來訪問受保護的資源。客戶端會將訪問令牌放入HTTP請求的Authorization頭中，作為Bearer令牌：

示例API請求：

GET /resource HTTP/1.1
Host: resource-server.com
Authorization: Bearer ACCESS_TOKEN

8. 資源伺服器驗證令牌並返回資源

資源伺服器接收到訪問令牌後，會向授權伺服器驗證令牌的有效性。如果令牌有效且許可權足夠，資源伺服器會返回請求的資源。

五、OAuth 2.0 的授權模式

除了授權碼模式（Authorization Code Grant），OAuth 2.0 還支援其他幾種常見的授權模式，適用於不同場景：

  1. 隱式授權模式（Implicit Grant）：主要用於單頁應用（SPA）或移動應用，客戶端直接在瀏覽器中接收訪問令牌，無需透過伺服器端換取授權碼。這種模式不涉及重新整理令牌，因為安全性較低，適用於短期使用場景。

  2. 密碼授權模式（Resource Owner Password Credentials Grant）：使用者將其憑據（使用者名稱和密碼）直接提供給客戶端應用，客戶端再用這些憑據向授權伺服器請求訪問令牌。這種模式一般不建議使用，除非客戶端是受信任的應用。

  3. 客戶端憑據模式（Client Credentials Grant）：客戶端以自己的身份（而非使用者的身份）請求訪問受保護的資源。這通常用於應用程式間的服務（如微服務）之間的授權，而非使用者授權。

  4. 重新整理令牌（Refresh Token Grant）：當訪問令牌過期時，客戶端可以使用重新整理令牌獲取新的訪問令牌，而無需再次向使用者請求授權。

六、OAuth 2.0 的優勢

  1. 安全性增強：OAuth 2.0允許應用程式在不暴露使用者憑據的情況下訪問資源，降低了憑據洩露的風險。

  2. 使用者體驗好：使用者只需授權一次，而無需每次都輸入使用者名稱和密碼，極大提高了使用者體驗。

  3. 靈活的授權管理：使用者可以控制授權的範圍，並且隨時可以撤銷授權，保證了授權的靈活性和安全性。

  4. 跨平臺支援：OAuth 2.0 可用於Web應用、移動應用、桌面應用等多種

環境，廣泛支援。

七、總結

OAuth 2.0 是一種安全、靈活的授權協議，解決了在不同平臺和服務之間安全地共享資源的問題。透過使用訪問令牌，OAuth 2.0 可以確保第三方應用程式能夠安全地訪問使用者的資源，同時使用者對授權過程有充分的控制。

相關文章