通过 Lambda 的 API 网关自定义授权方的正确主体 ID 值？

Question

我正在使用 API Gateway 的一项新功能和 Lambda 函数来使用 自定义授权者 (https://docs.aws.amazon.com/apigateway/latest/developerguide/use-custom-authorizer.html)。

授权方使用 JWT 令牌 来验证当前用户上下文和范围的令牌。一切正常，但有一个关于 AWS 策略的概念，我无法从文档中完全弄清楚。

Custom Authorizer 函数的输出必须是一个包含两个东西的对象：

1. principalId - 有问题
2. policyDocument - 有效的策略文档，其中包含允许用户授权访问 Lambda 资源、阶段等的声明。

现在，自定义授权者的示例当前显示了 principalId 变量的几乎任意值。但是，如果我的想法正确的话，这个principalId 对于每个用户来说应该是唯一的吗？并且可能具有与之关联的用户特定的唯一值（例如token.userId 或token.email）。

如果这是真的，那么对于我在下面提供的代码，如果 JWT 令牌 not 有效，那么我无权访问 userId 或 email，并且没有任何线索将principalId 设置为什么。我暂时将其设置为user，只是为了让拒绝策略返回一些东西，以确保响应是403 Forbidden。

谁知道为自定义授权者设置principalId的最佳实践？

var jwt = require('jsonwebtoken');
var JWT_SECRET = 'My$ecret!';


/**
 * Implicit AWS API Gateway Custom Authorizer. Validates the JWT token passed
 * into the Authorization header for all requests.
 * @param  {Object} event   [description]
 * @param  {Object} context [description]
 * @return {Object}         [description]
 */
exports.handler = function(event, context) {
  var token = event.authorizationToken;
  try {
    var decoded = jwt.verify(token, JWT_SECRET);
    context.done(null, generatePolicy(decoded.id, 'Allow', 'arn:aws:execute-api:*:*:*'));
  } catch(ex) {
    console.error(ex.name + ": " + ex.message);
    context.done(null, generatePolicy('user', 'Deny', 'arn:aws:execute-api:*:*:*'));
  }
};

function generatePolicy(principalId, effect, resource) {
  var authResponse = {};
  authResponse.principalId = principalId;
  if (effect && resource) {
    var policyDocument = {};
    policyDocument.Version = '2012-10-17'; // default version
    policyDocument.Statement = [];
    var statementOne = {};
    statementOne.Action = 'execute-api:Invoke'; // default action
    statementOne.Effect = effect;
    statementOne.Resource = resource;
    policyDocument.Statement[0] = statementOne;
    authResponse.policyDocument = policyDocument;
  }
  return authResponse;
}

Answer 1

principalId 旨在表示被授权进行 API 调用的任何实体的长期标识符。因此，如果您有一个现有的用户数据库，那么每个用户可能都有一个唯一的标识符或用户名。您提到了“用户”，这可能很好。从功能上讲，如果您启用 CloudWatch Logs，principalId 会被记录，并且也是您可以在 $context 中访问的映射模板。

就您的功能设计而言，您有两种选择来处理“无效”令牌。

1. 如果您返回拒绝访问的有效策略，这会通过缓存与令牌关联的策略以防再次使用，从而帮助您减少 Lambda 调用。但是，客户端可能会收到 403 并认为令牌是有效的，但他们无权访问他们请求的资源。

2. context.fail("Unauthorized") 将向客户端发送一个 401 响应错误，这应该向他们表明令牌无效。这将有助于客户端，但如果客户端反复重放错误令牌，也会导致对该函数的更多调用。负缓存目前在该功能上不可用，但提供适度保护的另一种方法是使用 'identityValidationExpresion' -> http://docs.aws.amazon.com/apigateway/api-reference/resource/authorizer/#identityValidationExpression

此外，我强烈建议您将其迁移到基于 apigateway-authorizer-nodejs 蓝图的新 Lambda 函数，因为文档中的代码示例很少且仅用于说明。该蓝图有许多记录各种用途的 cmets，例如 fail("Unauthorized") 功能。