[Oauth2](https://help.sap.com/viewer/d0224eca81e249cb821f2cdf45a82ace/1905/en-US/3d3ea6a4d5fa486aa324ce278fa2afc3.html)

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

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

```xml
<extension name="oauth2"></extension>
```

支援的配置：

![](https://img-blog.csdnimg.cn/img_convert/bc7b03c2f5ef01d7e108b1b6c9e56617.png)

* 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/authorizationserver/oauth/token

下圖是新的 token 請求的 form data 欄位，輸入欄位：
![](https://img-blog.csdnimg.cn/img_convert/dfc624044cdb1aa27ab489737a6e9f4f.png)

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

![](https://img-blog.csdnimg.cn/img_convert/0535a453fb4d01f6ade3fea6ac305177.png)

# 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 需要在本地持久化，這比儲存使用者憑證要好。 下圖描述了此流程。

![](https://img-blog.csdnimg.cn/img_convert/affdbbe6bb50e5e61a235911eb5bf4f0.png)

所呈現流程的詳細說明：

步驟 (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 必須記住使用者憑據，這是一種不太安全的方法。 提供訪問令牌並重新整理令牌意味著客戶端只需記住令牌。</access_token>

SAP Commerce Cloud OAuth 實現介紹

相關文章