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的原创文章，尽在："汪子熙":