乐趣区

关于sap:SAP-Commerce-Cloud-OAuth-实现介绍

jiezi

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

退出移动版