Oauth2

oauth2 core extension 已經(jīng)取代了 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 開發(fā)者工具 local storage 里把 auth token 刪除之后，隨便在 UI 上再操作一下，會重新觸發(fā) token 請求：https://20.51.210.49:9002/authorizationserver/oauth/token

下圖是新的 token 請求的 form data 字段，輸入字段：

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

OAuth2 里的幾個角色

• 資源所有者：可以授予對受保護資源的訪問權限的實體。 當資源所有者是個人時，則稱為：最終用戶。

• 資源服務器：托管受保護資源的服務器，能夠使用訪問令牌接受和響應受保護資源請求。

• 客戶端：代表資源所有者并經(jīng)其授權發(fā)出受保護資源請求的應用程序。術語客戶端并不意味著任何特定的實現(xiàn)特征（例如，應用程序是否在服務器、桌面或任何其他特定設備上運行）。

• 授權服務器：服務器在成功驗證資源所有者并獲得授權后向客戶端頒發(fā)訪問令牌。

• 授權服務器在 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 不太受信任，并且不會發(fā)出刷新令牌。 這適用于需要臨時訪問的客戶端 Web 應用程序。

客戶端憑據(jù)流 Client Credentials Flow 使客戶端可以訪問其擁有的資源。

根據(jù)您的客戶端應用程序，您需要選擇合適的流程。您還需要禁用您不使用的其他流。

Resource Owner Password Flow

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

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

所呈現(xiàn)流程的詳細說明：

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

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

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

username 和 password：資源所有者的憑據(jù)，用戶的真實憑據(jù)。

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

步驟?：認證服務器返回帶有可選的refersh_token的access_token。

Refreshing an Expired Access Token

需要刷新下發(fā)的access_token。 如果不刷新這些令牌，client 必須記住用戶憑據(jù)，這是一種不太安全的方法。 提供訪問令牌并刷新令牌意味著客戶端只需記住令牌。

更多Jerry的原創(chuàng)文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的SAP Commerce Cloud OAuth 实现介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。