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" /> 支持的配置:
Authorization ServerThe authorization server exposes two endpoints:
在 Chrome 开发者工具 local storage 里把 auth token 删除之后,随便在 UI 上再操作一下,会重新触发 token 请求:https://20.51.210.49:9002/authorizationserver/oauth/token 下图是新的 token 请求的 form data 字段,输入字段: 下图是服务器返回的新的 Access Token 和 Refresh token: OAuth2 里的几个角色
OAuth 2.0 带有四个流程。 SAP Commerce 支持所有这些:
如果 Web 应用程序可以保留 client_secret,则最好使用授权代码流 Authorization Code Flow。 隐式流 Implicit Flow 不需要任何授权令牌。 因此,它更容易但不太安全。 在浏览器中运行的 JavaScript 不太受信任,并且不会发出刷新令牌。 这适用于需要临时访问的客户端 Web 应用程序。 客户端凭据流 Client Credentials Flow 使客户端可以访问其拥有的资源。 根据您的客户端应用程序,您需要选择合适的流程。您还需要禁用您不使用的其他流。 Resource Owner Password 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。 Refreshing an Expired Access Token需要刷新下发的access_token。 如果不刷新这些令牌,client 必须记住用户凭据,这是一种不太安全的方法。 提供访问令牌并刷新令牌意味着客户端只需记住令牌。 |
|