Question

我们有这样的REST资源：

/customer/{customerId}/bill

我们想要使用从AWS Cognito返回的JWT令牌来保护对该资源的访问。

此处的{customerId}不是Cognito用户ID，它是特定于域的ID。我们已将此域特定的ID作为自定义属性添加到Cognito用户。它包含在Cognito这样返回的ID令牌中：

{
  "sub": "xxxxxxxx-852f-474d-aa9e-a50fd832bcb8",
  "aud": "xxxxxxxxsijed6uf54dh0uhi",
  "custom:customerId": "4044",
  "event_id": "xxxxxx-fc0c-4ffc-affa-f8987714fb2b",
  "token_use": "id",
  ....
}

如果我们在Authorization: Bearer <ID Token>中使用此ID令牌，我们可以编写代码（自定义授权者或应用内代码），以确保customerId中的/customer/{customerId}/bill等于{{ 1}}中，我们已经保护了我们的API。

但是我们读了that you should not use ID tokens to secure APIs。关键是：

“ （ID）令牌的受众（音频声明）被设置为应用程序的标识符，这意味着只有该特定应用程序才应使用此令牌。”

因此，似乎我们需要发送访问令牌以保护API。使用Cognito，我们无法将用户身份的任何概念添加到访问令牌中。例如，我们无法添加自定义范围，例如custom:customerId。

人们在这里建议的一种方法是使用提供的访问令牌在服务器端调用Cognito的user:4044端点，以了解用户是谁。这将使我们能够编写调用此终结点并声明权限的代码（自定义授权者或应用内代码）。但这是每个请求的终结点调用，这似乎很疯狂。

一个想到的想法是使用访问令牌来保护对API本身的访问，但是还需要ID令牌（作为查询参数或标头），以允许我们进行细粒度的访问控制。但这也开始让人感到不对。

这肯定是一个解决的问题吗？在这里做什么正确的事？

Answer 1

对不起，这个问题已经一岁了，所以我的回答可能无关紧要。但是对于未来的流浪者，我要说的是，鉴于cognito允许在访问令牌中进行自定义声明的局限性，调用/ userinfo路由绝对是最好的方法。

API GATEWAY使您可以缓存给定用户的授权者响应，因此您不会在每个请求上都调用端点。请注意，某些实现建议将其作为确保未撤消令牌的一种方式。

当访问令牌中没有身份时，如何使用JWT将用户限制在其资源上？

1 个答案: