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小时
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 字段,输入字段:
下图是服务器返回的新的 Access Token 和 Refresh token:
资源所有者:可以授予对受保护资源的访问权限的实体。 当资源所有者是个人时,则称为:最终用户。
资源服务器:托管受保护资源的服务器,能够使用访问令牌接受和响应受保护资源请求。
客户端:代表资源所有者并经其授权发出受保护资源请求的应用程序。术语客户端并不意味着任何特定的实现特征(例如,应用程序是否在服务器、桌面或任何其他特定设备上运行)。
授权服务器:服务器在成功验证资源所有者并获得授权后向客户端颁发访问令牌。
授权服务器在 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 使客户端可以访问其拥有的资源。
根据您的客户端应用程序,您需要选择合适的流程。您还需要禁用您不使用的其他流。
此流程有点类似于基本身份验证 basic authentication 流程,但它有一些好处。 它通常用于受信任的移动应用程序,例如移动 Android 或 iOS 应用程序。 该流程包括将用户的 username 和 password 发送到令牌端点以换取 。 服务器端使用刷新令牌回复是可选的。 移动 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。
需要刷新下发的access_token。 如果不刷新这些令牌,client 必须记住用户凭据,这是一种不太安全的方法。 提供访问令牌并刷新令牌意味着客户端只需记住令牌。
联系客服