使用 OAuth 20 在 Amazon Cognito 中的指南

关键要点

理解 OAuth 20 的授权类型对于实现安全的身份验证和授权机制至关重要。Amazon Cognito 支持多种不同的 OAuth 20 授权类型，包括授权码授权、客户端凭证授权等。在实际应用中，利用这些授权类型可以增强应用程序的安全性和用户体验。

在现代应用程序中实现身份验证和授权机制可能面临挑战，特别是在处理不同客户端类型和用例时。作为开发人员，我们常常在选择合适的身份验证流程时面临困难，需要在安全性、用户体验和应用程序需求之间找到平衡。这时，理解 OAuth 20 授权类型就显得尤为重要。无论是构建传统的 Web 应用程序、移动应用，还是机器对机器的通信系统，理解 OAuth 20 授权类型都能帮助你实现强大且安全的身份验证和授权机制。

本文将向你展示不同的 OAuth 20 授权方式以及如何在 Amazon Cognito 中实施它们。我们将回顾每种授权的目的、在现代应用程序开发中的相关性，以及哪种授权最适合不同的应用需求。

OAuth 20 的基本概念

OAuth 20 是一种授权框架，允许用户在不共享敏感凭据的情况下，安全、无缝地访问资源。OAuth 20 的主要目标是建立一个安全的、委托的、范围有限的访问机制，使第三方应用能够与用户数据进行交互，同时保持强大的隐私和安全措施。

OpenID Connect简称 OIDC是基于 OAuth 20 的协议。它扩展了OAuth 20 以提供用户身份验证、身份验证验证和用户信息检索。OIDC 是构建安全且用户友好身份验证体验的关键组成部分。Amazon Cognito 支持 OIDC，这意味着它支持根据 OIDC 标准进行用户身份验证和身份验证验证。

Amazon Cognito 是一个用于 Web 和移动应用的身份环境。其主要组件包括 用户池 和 身份池。Cognito 用户池是一个用户目录，是 OAuth 20 令牌的身份验证服务器和授权服务。凭借它，你可以本地或通过受保护身份如企业目录验证和授权用户，或通过 Google 或 Facebook 等消费者身份提供者。Cognito 身份池可以将 OAuth 20 令牌和其他选项交换为 AWS 凭证。

在 Amazon Cognito 中实现 OAuth 20 授权

OAuth 20 标准定义了四个主要角色，这些角色在讨论授权时非常重要：

资源所有者 拥有资源服务器中的数据，并可以授予访问权限例如，数据库管理员。资源服务器 托管应用程序希望访问的受保护资源例如 SQL 服务器。客户端 是代表资源所有者并经其授权请求受保护资源的应用程序例如，分析应用。授权服务器 是在用户身份验证并同意在所需范围内发放令牌后发放有范围的令牌的服务器例如 Amazon Cognito。

在深入讨论 OAuth 20 授权之前，还有几个其他重要概念：

访问令牌 是 OAuth 20 操作的核心。这些令牌是短期的凭证，客户端应用程序使用它们来证明其在请求资源时的授权状态。此外，OAuth 20 可能涉及使用 刷新令牌，该令牌为客户端提供在不需要资源所有者干预的情况下获取新访问令牌的机制。ID 令牌 是 OpenID Connect 引入的 JSON Web 令牌JWT，包含有关用户身份验证事件的信息。它们允许应用程序验证用户身份，做出有关用户身份验证状态的明智决策，并个性化用户体验。范围 是应用程序可以请求对资源的访问层级。范围定义了客户端应用程序在获取访问令牌时可以请求的特定权限。通过使用范围，可以微调授予客户端的访问级别。例如，OAuth 20 请求可能包括范围 readprofile，表示客户端应用程序请求对用户个人资料信息的只读访问权限。

一个典型的高层次 OAuth 20 流程如下图所示：

OAuth 20 流程的步骤

客户端向资源所有者请求授权。此请求通过授权服务器Amazon Cognito作为中介进行。资源所有者向客户端提供授权许可。这可以是多种授权类型之一，具体讨论将在下文进行。使用哪种授权类型取决于客户端向资源所有者请求授权的方法。客户端通过向 Cognito 进行身份验证请求访问令牌。Cognito 身份验证客户端基于授权类型的身份验证方法，并在授权有效时发放访问令牌。访问令牌在客户端请求受保护资源时呈现给资源服务器。资源服务器检查访问令牌的签名和属性，如果有效，则处理请求。

接下来将详细说明几种不同的授权类型。

授权码授权

授权码授权类型用于客户端安全地交换授权码以获取访问令牌。无论是 Web 应用程序还是原生应用程序，均使用此授权类型在用户向应用程序身份验证后获取访问令牌。在用户通过重定向 URI身份验证服务器在授权用户后重定向浏览器的 URL返回到客户端后，应用程序从 URL 中获取授权码并使用它请求访问令牌。

此授权类型适合一般情况下，因为只使用一种身份验证流程，无论执行什么操作或由谁执行。此授权被认为是安全的，因为它请求使用单次授权码来获取访问令牌，而不是暴露实际的访问令牌。这有助于防止应用程序可能访问用户凭据。

授权码授权流程的步骤

过程从客户端发起，指导资源所有者的用户代理即浏览器到授权端点。在此操作中，客户端提供其客户端标识符、请求的范围、一个本地状态和重定向 URI，授权服务器Amazon Cognito将在授权或拒绝访问后将用户代理返回。Cognito 通过用户代理验证资源所有者，并确定资源所有者是否授予或拒绝客户端的访问请求。Cognito 将用户代理重定向回客户端，使用第1步中提供的重定向 URI，并在查询字符串中附带授权码。客户端通过包含步骤3中接收到的授权码向 Cognito 的令牌端点请求访问令牌。请求时，客户端通常用客户端 ID 和密钥向 Cognito 身份验证。客户端包含用于获取授权码的重定向 URI 以供验证。Cognito 验证客户端，验证授权码，并确保收到的重定向 URI 与步骤3中重定向客户端使用的 URI 匹配。如果有效，Cognito 以访问令牌作出响应。

以下是使用 Amazon Cognito 实现授权码授权的过程：

应用程序向 AUTHDOMAIN/oauth2/authorize 发出 HTTP GET 请求，其中 AUTHDOMAIN 表示用户池的配置域。此请求包括以下查询参数：responsetype 设置为 code。clientid 期望用户池 应用客户端 的 ID。redirecturi 用户在成功身份验证后重定向到的 URL。state可选但建议 用于防止 跨站请求伪造CSRF攻击的随机值。scope可选 请求生成令牌时的范围列表。注意：仅在请求 openid 范围时生成 ID 令牌。仅在同时请求 openid 时才能请求 phone、email 和 profile 范围。按照标准 OAuth 20 范围调用的可供出售访问令牌，只有在请求 awscognitosigninuseradmin用户池的保留 API 范围时才可用于调用用户池 API。identityprovider可选 指定最终用户应当使用的身份提供商进行身份验证。idpidentifier可选 与 identityprovider 相同，但未暴露实际名称。nonce可选 可以向请求添加的随机值。你提供的 nonce 值包含在 Amazon Cognito 发出的 ID 令牌中。你的应用可以检查 ID 令牌中的 nonce 声明并与生成的 nonce 进行比较，以防止重放攻击。有关 nonce 声明的更多信息，请参见 ID 令牌验证 中的 OpenID Connect 标准。CSRF 令牌在 cookie 中返回。如果在步骤 1 的请求中指定了身份提供商，则跳过此顺序的其他步骤。用户将自动重定向到适当身份提供商的身份验证页面。否则，用户将被重定向到 https//AUTHDOMAIN/login 托管生成的 UI并设置步骤 1 中的相同查询参数。然后他们可以选择通过用户池进行身份验证，或选择为指定的应用客户端配置的第三方提供者之一。用户通过以下方式之一与其身份提供商进行身份验证：如果用户使用原生用户池进行身份验证，则托管 UI 通过 POST 请求将用户凭据提交到 https//AUTHDOMAIN/login 包括原始查询参数以及一些额外的元数据。如果用户选择与其他身份提供商进行身份验证，则用户会被重定向到该身份提供商的身份验证页面。成功身份验证后，提供者将用户重定向到 https//AUTHDOMAIN/saml2/idpresponse，并附带查询参数中的授权令牌或 POST 请求中的 SAML 断言。在 Amazon Cognito 验证用户池凭据信息或提供者令牌后，用户会被重定向到最初在 redirecturi 查询参数中指定的 URL。重定向还设置了一个 code 查询参数，指定了返回给用户的授权码。在重定向 URL 托管的自定义应用程序可以提取查询参数中的授权码，并用其交换用户池令牌。通过向 https//AUTHDOMAIN/oauth2/token 提交 POST 请求来进行交换，使用以下 application/xwwwformurlencoded 参数：granttype 设置为 authorizationcode。code 返回给用户的授权码。clientid 与步骤 1 中宠爱相同。redirecturi 与步骤 1 中请求的一样。

如果客户端应用程序配置了密钥，则该请求的 Authorization 头设置为 Basic BASE64(CLIENTIDCLIENTSECRET)，其中 BASE64(CLIENTIDCLIENTSECRET) 是为了代替应用客户端 ID 和应用客户端密钥而拼接的 base64 表达

返回的 JSON 响应中包含以下键：

accesstoken 有效的用户池 访问令牌。refreshtoken 有效的用户池 刷新令牌，可以通过将其通过 POST 请求发送到 https//AUTHDOMAIN/oauth2/token 的方式来检索新令牌，同时指定 refreshtoken 和 clientid 参数，并设置 granttype 参数为 refreshtoken。idtoken 有效的用户池 ID 令牌。如果请求了 openid 范围，才会提供 ID 令牌。expiresin 提供的 ID 或访问令牌的有效时间长度以秒为单位。tokentype 设置为 Bearer。

使用授权码授权的最佳实践

在使用授权码授权时，使用代码交换的证明密钥PKCE扩展，尤其对于单页面 Web 应用等公共客户端。这将在以下章节中详细讨论。定期旋转客户端密钥和凭证，以最小化未授权访问的风险。实施会话管理以安全处理用户会话，这涉及管理 访问令牌的生命周期、存储令牌、轮换刷新令牌、实施令牌撤消机制，以及提供简单的 注销 机制，以使用户设备上的访问令牌和刷新令牌失效。

使用 PKCE 的授权码授权

为增强使用授权码授权的安全性，特别是在公共客户端如本地应用程序中，引入了 PKCE 扩展。PKCE 通过确保只有启动授权过程的客户端才能将收到的授权码交换为访问令牌，从而增加了一层保护。这种组合有时称为 PKCE 授权。

它引入了一个称为 代码验证器 的秘密值，这是客户端为每个授权请求生成的一个随机值。随后使用像 SHA256 这样的转换方法对该值进行哈希，这被称为代码挑战。在此过程中遵循与图 2 相同的步骤，但在对授权服务器Amazon Cognito请求时，现在还添加了代码挑战。授权服务器存储此代码挑战以便在身份验证过程后进行验证，并重定向回带有授权码的请求。此授权码与代码验证器一起发送到授权服务器，授权服务器随后将先前存储的代码挑战与代码验证器进行比较。在验证成功完成后，发放访问令牌。

带有 PKCE 的授权码授权的实现

带有 PKCE 的授权码授权实现与普通授权码授权相同，唯一的区别是第 1 步需要两个附加查询参数：

codechallenge 随机代码的哈希值经过 base64 URL 编码。它作为 PKCE 的用途，可防止不法分子使用截获的授权码。codechallengemethod 用于生成 codechallenge 的哈希算法。Amazon Cognito 目前仅支持将此参数设置为 S256，表示 codechallenge 参数是使用 SHA256 生成的。

在第 5 步中，交换授权码和用户池令牌时，增加一个额外的参数：

飞驰加速器官网codeverifier 零散的、未哈希的、用来在原始请求中生成 PKCE codechallenge 的随机字符串的 base64 URL 编码表示。

隐式授权不推荐

隐式授权是一种 OAuth 20 身份验证授权类型，允许客户端如单页面应用程序和移动应用直接从授权端点获取用户访问令牌。因为没有发出中间凭证如授权码，所以此授权类型被称为隐式授权。隐式授权已经被弃用，建议使用带有 PKCE 的授权码授权。使用隐式授权的后果是将访问令牌直接暴露在 URL 片段中，可能会在浏览器历史记录中保存、被截获，或暴露给同一设备上存在的其他应用程序。

![图 4 隐式授权流程](https//d2908q01vom