博客 / 詳情

返回

SAP Commerce Cloud OAuth 實現介紹

Oauth2

oauth2 core extension 已經取代了 webservicescommons/oauthauthorizationserver 擴展。 它將 HTTP 端點公開為 Authorization 服務器。 它沒有引入任何新的重要功能。

To enable the authorization server, add the oauth2 extension entry into the localextensions.xml file:

<extension name="oauth2" />

支持的配置:

  • oauth2.refreshTokenValiditySeconds:Refresh token time-to-live,默認30天
  • oauth2.accessTokenValiditySeconds: Access token time-to-live,默認12小時

Authorization Server

The authorization server exposes two endpoints:

  • /oauth/authorize
  • /oauth/token

在 Chrome 開發者工具 local storage 裏把 auth token 刪除之後,隨便在 UI 上再操作一下,會重新觸發 token 請求:https://20.51.210.49:9002/aut...

下圖是新的 token 請求的 form data 字段,輸入字段:

下圖是服務器返回的新的 Access Token 和 Refresh token:

OAuth2 裏的幾個角色

  • 資源所有者:可以授予對受保護資源的訪問權限的實體。 當資源所有者是個人時,則稱為:最終用户。
  • 資源服務器:託管受保護資源的服務器,能夠使用訪問令牌接受和響應受保護資源請求。
  • 客户端:代表資源所有者並經其授權發出受保護資源請求的應用程序。術語客户端並不意味着任何特定的實現特徵(例如,應用程序是否在服務器、桌面或任何其他特定設備上運行)。
  • 授權服務器:服務器在成功驗證資源所有者並獲得授權後向客户端頒發訪問令牌。
  • 授權服務器在 Oauth2 中定義,示例資源服務器在 ycommercewebservices Extension 和 ywebservices Extension 中配置。

OAuth 2.0 帶有四個流程。 SAP Commerce 支持所有這些:

  • 由於 Resource Owner Password Flow 持有用户的 username 和 password,因此安全性較低,不適用於第三方應用程序。

如果 Web 應用程序可以保留 client_secret,則最好使用授權代碼流 Authorization Code Flow。

隱式流 Implicit Flow 不需要任何授權令牌。 因此,它更容易但不太安全。 在瀏覽器中運行的 JavaScript 不太受信任,並且不會發出刷新令牌。 這適用於需要臨時訪問的客户端 Web 應用程序。

客户端憑據流 Client Credentials Flow 使客户端可以訪問其擁有的資源。

根據您的客户端應用程序,您需要選擇合適的流程。您還需要禁用您不使用的其他流。

Resource Owner Password Flow

此流程有點類似於基本身份驗證 basic authentication 流程,但它有一些好處。 它通常用於受信任的移動應用程序,例如移動 Android 或 iOS 應用程序。 該流程包括將用户的 username 和 password 發送到令牌端點以換取 <access_token>。 服務器端使用刷新令牌回覆是可選的。 移動 client 否則必須保留用户名和密碼以便長期訪問。

流需要 username 和 password 來獲得 access_token。 但是,請記住,API 提供程序提供結合了 refresh_token 的訪問令牌。 因此客户端不需要保存用户名和密碼,而只需要傳遞這些信息。 access_token 和 refresh_token 需要在本地持久化,這比存儲用户憑證要好。 下圖描述了此流程。

所呈現流程的詳細説明:

步驟 (A):client 接收 username 和 password。在此步驟中,用户將此信息直接輸入到客户端應用程序中。請注意,用户必須有辦法將應用程序識別為他們可以信任的官方應用程序。

步驟 (B):接下來,客户端應用程序向授權服務器發出請求,例如 /oauth/token 端點。 client_id 和 client_secret 可以通過兩種方式發送:在常規的基本身份驗證請求標頭中,或作為在請求有效負載(即請求正文)中傳遞的參數的一部分。查看要傳遞的參數列表:

client_id 和 client_secret:作為參數或作為基本身份驗證標頭傳遞。基本身份驗證意味着 client_id 和 client_secret 被視為用户名和密碼,使用冒號 (:) 連接,然後進行 Base64 編碼。然後將此值用作授權請求標頭的一部分,例如: Authorization: Basic Base64-encoded username:password

username 和 password:資源所有者的憑據,用户的真實憑據。

grant_type:此流程需要設置為 password。

步驟(C):認證服務器返回帶有可選的refersh_token的access_token。

Refreshing an Expired Access Token

需要刷新下發的access_token。 如果不刷新這些令牌,client 必須記住用户憑據,這是一種不太安全的方法。 提供訪問令牌並刷新令牌意味着客户端只需記住令牌。

更多Jerry的原創文章,盡在:"汪子熙":

user avatar
0 位用戶收藏了這個故事!

發佈 評論

Some HTML is okay.