原文链接：http://www-01.ibm.com/support/knowledgecenter/SSELE6_8.0.0.3/com.ibm.ammob.doc_8.0.0.3/config/concept/con_oauth20_workflow.html%23con_oauth20_workflow?lang=zh

两种认证模式区别见：http://stackoverflow.com/questions/7522831/what-is-the-purpose-of-the-implicit-grant-authorization-type-in-oauth-2

OAuth 2.0 工作流程

IBM Security Access Manager 中的 OAuth 2.0 支持使 OAuth 客户机能够通过四种不同的方式获取对受保护资源的访问权。

OAuth 2.0 工作流程

Security Access Manager for Mobile 支持下列 OAuth 2.0 工作流程。

授权代码流程(适用于有服务器端的应用)

授权代码授予类型适用于那些向授权服务器进行认证时可以对其客户机凭证进行保密的 OAuth 客户机。例如，在安全服务器上实现的客户机。作为基于重定向的流程，OAuth 客户机必须能够与资源所有者的用户代理进行交互。它还必须能够通过重定向接收来自授权服务器的传入请求。

授权代码工作流程图包括下列步骤：

1. OAuth 客户机会在将资源所有者的用户代理定向到授权端点时启动流程。OAuth 客户机包括其客户机标识、所请求的作用域、本地状态以及重定向 URI。在准予或拒绝访问之后，授权服务器会将用户代理发回到重定向 URI。
2. 授权服务器通过用户代理对资源所有者进行认证，并确定资源所有者是准予还是拒绝访问请求。
3. 如果资源所有者准予访问，那么 OAuth 客户机将使用先前提供的重定向 URI 将用户代理重定向回 OAuth 客户机。重定向 URI 包括授权代码以及 OAuth 客户机先前提供的所有本地状态。
4. OAuth 客户机通过令牌端点从授权服务器请求访问令牌。OAuth 客户机使用其客户机凭证进行认证，并包括上一步中接收到的授权代码。OAuth 客户机还提供了用于获取授权代码以进行验证的重定向 URI。
5. 授权服务器验证客户机凭证和授权代码。此服务器还将确保接收到的重定向 URI 与步骤 3 中用于重定向客户机的 URI 相匹配。如果有效，那么授权服务器将使用访问令牌进行回应。

授权服务器可以是资源服务器，也可以是另一实体。单个授权服务器可以发放多个资源服务器接受的访问令牌。

使用刷新令牌的授权代码流程

使用刷新令牌的授权代码工作流程图包括下列步骤：

1. OAuth 客户机通过使用其客户机凭证向授权服务器进行认证并出示权限授予来请求访问令牌。
2. 授权服务器验证客户机凭证和权限授予。如果有效，那么授权服务器将发放访问令牌和刷新令牌。
3. OAuth 客户机通过出示访问令牌向资源服务器发出访问受保护资源的请求。
4. 资源服务器验证访问令牌。如果访问令牌有效，那么资源所有者将为该请求提供服务。
5. 重复步骤 3 和 4，直到访问令牌到期。如果 OAuth 客户机知道访问令牌已到期，请跳至步骤 7。否则，OAuth 客户机将发出访问另一个受保护资源的请求。
6. 如果访问令牌无效，那么资源服务器将返回错误。
7. OAuth 客户机通过使用其客户机凭证向授权服务器进行认证并出示刷新令牌来请求新的访问令牌。
8. 授权服务器验证客户机凭证和刷新令牌，并且在这些凭证和令牌有效的情况下发放新的访问令牌和新的刷新令牌。

隐式授予流程

隐式授予类型适用于那些无法对其用于向授权服务器认证的客户机凭证进行保密的客户机。例如用户代理中的客户机应用程序，这些应用程序通常使用 JavaScript 之类的脚本语言在浏览器中进行实现。

作为基于重定向的流程，OAuth 客户机必须能够与资源所有者的用户代理（通常是 Web 浏览器）进行交互。OAuth 客户机还必须能够通过重定向接收来自授权服务器的传入请求。

隐式授予工作流程图包含下列步骤：

1. OAuth 客户机通过将资源所有者的用户代理定向到授权端点来启动流程。OAuth 客户机包括其客户机标识、所请求的作用域、本地状态以及重定向 URI。在准予或拒绝访问之后，授权服务器会将用户代理发回到重定向 URI。
2. 授权服务器通过用户代理对资源所有者进行认证，并确定资源所有者是准予还是拒绝访问请求。
3. 如果资源所有者准予访问，那么授权服务器将使用先前提供的重定向 URI 将用户代理重定向回客户机。重定向 URI 将访问令牌包括在 URI 片段中。
4. 用户代理通过向 Web 服务器发出不包含该片段的请求来按重定向指示信息进行操作。用户代理将在本地保留片段信息。
5. Web 服务器返回一个 Web 页面，此页面通常是包含嵌入式脚本的 HTML 文档。此 Web 页面将访问完全重定向 URI，其中包括用户代理所保留的片段。它还可以抽取该片段中包含的访问令牌及其他参数。
6. 用户代理在本地运行 Web 服务器提供的脚本，这将抽取访问令牌并将其传递到客户机。

资源所有者密码凭证流程

资源所有者密码凭证授予类型适用于资源所有者与客户机之间具有信任关系的情况。例如，资源所有者可以是 OAuth 客户机的计算机操作系统，也可以是具有高级别特权的应用程序。

只有当 OAuth 客户机已获取资源所有者的凭证时，您才能使用此授予类型。此授予类型还可以通过将存储的凭证转换为访问令牌，对使用直接认证方案的现有客户机进行迁移。

资源所有者密码凭证工作流程图包括下列步骤：

1. 资源所有者为客户机提供其用户名和密码。
2. OAuth 客户机通过令牌端点从授权服务器请求访问令牌。OAuth 客户机使用其客户机凭证进行认证，并包括从资源所有者接收到的凭证。
3. 在验证资源所有者凭证和客户机凭证之后，授权服务器发放访问令牌和（可选）刷新令牌。

客户机凭证流程

当 OAuth 客户机仅使用其客户机凭证请求访问令牌时，将使用客户机凭证流程。此流程适用于下列其中一种情况：

• OAuth 客户机请求在其控制下访问受保护资源。
• OAuth 客户机请求访问其他受保护资源，而该资源的授权先前已通过授权服务器进行安排。

客户机凭证工作流程图包括下列步骤：

1. OAuth 客户机通过使用其客户机凭证进行认证来从令牌端点请求访问令牌。
2. 在验证客户机凭证之后，授权服务器发放访问令牌。

• OAuth 2.0 令牌端点中的客户机认证注意事项
  OAuth 2.0 令牌端点用于 OAuth 客户机与授权服务器之间的直接通信。令牌端点用于获取 OAuth 令牌。
• 使用 WebSEAL 作为联系点来配置认证令牌端点
  使用 WebSEAL 作为联系点来配置认证令牌端点以将客户机认证委派给 WebSEAL。

用户代理在Authorization Code下为web server端服务，在Implicit_Grant下可以为浏览器