Use autorizadores AWS Lambda com um provedor de identidade de terceiros para proteger as APIs REST no Amazon API Gateway

Observação: esta postagem se concentra nas APIs REST do Amazon API Gateway usadas com OAuth 2.0 e autorizadores personalizados do AWS Lambda. O API Gateway também oferece APIs HTTP que fornecem recursos OAuth 2.0 nativos. Para obter mais informações sobre o que é adequado para sua organização, consulte Escolher entre APIs HTTP e REST.

O Amazon API Gateway é um serviço AWS totalmente gerenciado que simplifica o processo de criação e gerenciamento de APIs REST em qualquer escala. Se você é novo com o API Gateway, confira o Amazon API Gateway Getting Started para se familiarizar com os principais conceitos e terminologia. Nesta postagem, demonstrarei como uma organização que usa um provedor de identidade terceiro pode usar autorizadores AWS Lambda para implementar um esquema de autorização baseado em token padrão para APIs REST implantadas usando o API Gateway.

No contexto deste post, um provedor de identidade terceiro refere-se a uma entidade que existe fora da AWS e que cria, gerencia e mantém informações de identidade para sua organização. Este provedor de identidade emite tokens assinados criptograficamente para usuários contendo informações sobre a identidade do usuário e suas permissões. Para usar esses tokens “não AWS” para controlar o acesso a recursos no API Gateway, você precisará definir um código de autorização personalizado usando uma função do Lambda para “mapear” as características do token para recursos e permissões do API Gateway.

Definir o código de autorização personalizado não é a única maneira de implementar a autorização no API Gateway e garantir que os recursos só possam ser acessados pelos usuários corretos. Além dos autorizadores Lambda, o API Gateway oferece várias opções “nativas” que usam os serviços existentes da AWS para controlar o acesso a recursos e não exigem nenhum código personalizado. Para saber mais sobre as práticas estabelecidas e os mecanismos de autorização, consulte Controlar e gerenciar acesso a uma API REST no API Gateway.

Os autorizadores Lambda são uma boa opção para organizações que usam provedores de identidade de terceiros diretamente (sem federação) para controlar o acesso a recursos no API Gateway ou organizações que exigem lógica de autorização além dos recursos oferecidos pelos mecanismos de autorização “nativos”.

Benefícios do uso de tokens de terceiros com o API Gateway

O uso de um autorizador Lambda com tokens de terceiros no API Gateway pode fornecer os seguintes benefícios:

Integração do provedor de identidade de terceiros com o API Gateway: se sua organização já adotou um provedor de identidade de terceiros, criar um autorizador Lambda permite que os usuários acessem os recursos do API Gateway usando suas credenciais de terceiros sem precisar configurar serviços adicionais, como Amazon Cognito. Isso pode ser particularmente útil se sua organização estiver usando o provedor de identidade terceiro para login único (SSO).

Impacto mínimo nos aplicativos clientes: se sua organização tiver um aplicativo que já esteja configurado para entrar em um provedor de identidade de terceiros e emitir solicitações usando tokens, serão necessárias alterações mínimas para usar esta solução com o API Gateway e um autorizador Lambda. Usando as credenciais de seu provedor de identidade existente, você pode integrar recursos do API Gateway em seu aplicativo da mesma maneira que os recursos não AWS são integrados.

Flexibilidade da lógica de autorização: os autorizadores do Lambda permitem a personalização adicional da lógica de autorização, além da validação e inspeção de tokens.

Visão geral da solução

O diagrama a seguir mostra o fluxo de autenticação/autorização para usar tokens de terceiros no API Gateway:

Figura 1: Exemplo de arquitetura de solução

Após um login bem-sucedido, o provedor de identidade terceiro emite um token de acesso para um cliente.
O cliente emite uma solicitação HTTP para o API Gateway e inclui o token de acesso no cabeçalho de autorização HTTP.
O recurso API Gateway encaminha o token para o autorizador do Lambda.
O autorizador do Lambda autentica o token com o provedor de identidade terceiro.
O autorizador Lambda executa a lógica de autorização e cria uma política de gerenciamento de identidade.
O API Gateway avalia a política de gerenciamento de identidade em relação ao recurso do API Gateway que o usuário solicitou e permite ou nega a solicitação. Se permitido, o API Gateway encaminha a solicitação do usuário para o recurso do API Gateway.

Pré-requisitos

Para construir a arquitetura descrita na visão geral da solução, você precisará do seguinte:

Um provedor de identidade: os autorizadores do Lambda podem trabalhar com qualquer tipo de provedor de identidade e formato de token. A postagem usa um provedor de identidade OAuth 2.0 genérico e JSON Web Token (JWT).
Uma API REST do API Gateway: você eventualmente configurará esta API REST para contar com o autorizador do Lambda para controle de acesso.
Um meio de recuperar tokens de seu provedor de identidade e chamar recursos do API Gateway: pode ser um aplicativo da Web, um aplicativo móvel ou qualquer aplicativo que dependa de tokens para acessar recursos de API.

Para a API REST neste exemplo, uso o API Gateway com uma integração simulada. Para criar essa API por conta própria, você pode seguir o passo a passo em Configurar integrações simuladas no API Gateway.

Você pode usar qualquer tipo de cliente para recuperar tokens de seu provedor de identidade e emitir solicitações para o API Gateway, ou consultar a documentação de seu provedor de identidade para verificar se é possível recuperar tokens diretamente e emitir solicitações usando uma ferramenta de terceiros, como Postman.

Antes de prosseguir com a criação do autorizador Lambda, você deve ser capaz de recuperar tokens de seu provedor de identidade e emitir solicitações HTTP para seu recurso API Gateway com o token incluído no cabeçalho de autorização HTTP. Esta postagem pressupõe que o provedor de identidade emite tokens OAuth JWT, e o exemplo abaixo mostra uma solicitação HTTP endereçada ao recurso simulado do API Gateway com um token de acesso OAuth JWT no cabeçalho de autorização HTTP. Essa solicitação deve ser enviada pelo aplicativo cliente que você está usando para recuperar seus tokens e emitir solicitações HTTP para o recurso simulado do API Gateway.

# Exemplo de Requisição HTTP utilizando Bearer token\
GET /dev/my-resource/?myParam=myValue HTTP/1.1\
Host: rz8w6b1ik2.execute-api.us-east-1.amazonaws.com\
Authorization: Bearer eyJraWQiOiJ0ekgtb1Z5eEpPSF82UDk3...}

Construindo um autorizador Lambda

Quando você configura um autorizador do Lambda para servir como fonte de autorização para um recurso do API Gateway, o autorizador do Lambda é invocado pelo API Gateway antes que o recurso seja chamado. Confira o Fluxo de trabalho Auth do autorizador do Lambda para obter mais detalhes sobre como o API Gateway invoca e troca informações com os autorizadores do Lambda. A principal funcionalidade do autorizador do Lambda é gerar uma política de gerenciamento de identidade bem definida que determina as ações permitidas do usuário, como quais APIs o usuário pode acessar. O autorizador do Lambda usará as informações no token de terceiros para criar a política de gerenciamento de identidade com base nos documentos de “mapeamento de permissões” que você definir — discutirei esses documentos de mapeamento de permissões com mais detalhes abaixo.

Depois que o autorizador do Lambda gera uma política de gerenciamento de identidade, a política é retornada ao API Gateway e o API Gateway a usa para avaliar se o usuário tem permissão para invocar a API solicitada. Opcionalmente, você pode definir uma configuração no API Gateway para armazenar em cache automaticamente a política de gerenciamento de identidade para que as invocações de API subsequentes com o mesmo token não invoquem o autorizador do Lambda, mas usem a política de gerenciamento de identidade que foi gerada na última invocação.

Neste post, você criará seu autorizador Lambda para receber um token de acesso OAuth e validar sua autenticidade com o emissor do token e, em seguida, implementar a lógica de autorização personalizada para usar os escopos OAuth presentes no token para criar uma política de gerenciamento de identidade que determina quais APIs o usuário tem permissão para acessar. Você também configurará o API Gateway para armazenar em cache a política de gerenciamento de identidade que é retornada pelo autorizador do Lambda. Esses padrões fornecem os seguintes benefícios:

Aproveite os serviços de gerenciamento de identidade de terceiros: validar o token com o terceiro permite o gerenciamento consolidado de serviços como verificação de token, expiração de token e revogação de token.
Cache para melhorar o desempenho: armazenar em cache a política de gerenciamento de identidade e token no API Gateway elimina a necessidade de chamar o autorizador do Lambda para cada invocação. Armazenar uma política em cache pode melhorar o desempenho; no entanto, esse aumento de desempenho vem com considerações adicionais de segurança. Essas considerações são discutidas a seguir.
Limite o acesso com escopos OAuth: usar os escopos presentes no token de acesso, juntamente com a lógica de autorização personalizada, para gerar uma política de gerenciamento de identidade e limitar o acesso a recursos é uma prática OAuth familiar e serve como um bom exemplo de lógica de autenticação personalizável. Consulte Definição de escopos para obter mais informações sobre escopos OAuth e como eles são normalmente usados para controlar o acesso a recursos.

O autorizador Lambda é invocado com o seguinte objeto como parâmetro de evento quando o API Gateway é configurado para usar um autorizador Lambda com o payload de evento no token; consulte Entrada para um autorizador do Lambda do Amazon API Gateway para obter mais informações sobre os tipos de payloads compatíveis com os autorizadores do Lambda. Como você está usando um esquema de autorização baseado em token, usará o payload útil do evento de token. Esse payload útil contém o methodArn, que é o nome de recurso da Amazon (ARN) do recurso do API Gateway ao qual a solicitação foi endereçada. O payload também contém o authorizationToken, que é o token de terceiros que o usuário incluiu na solicitação.

# Lambda - Payload do Token de evento  
{   
 type: 'TOKEN',  
 methodArn: 'arn:aws:execute-api:us-east-1:2198525...',  
 authorizationToken: 'Bearer eyJraWQiOiJ0ekgt...'  
}

Ao receber esse evento, seu autorizador Lambda emitirá uma solicitação HTTP POST para seu provedor de identidade para validar o token e usar os escopos presentes no token de terceiros com um documento de mapeamento de permissões para gerar e retornar uma política de gerenciamento de identidade que contém as ações permitidas do usuário no API Gateway. Os autorizadores do Lambda podem ser escritos em qualquer linguagem compatível com o Lambda. Você pode explorar alguns modelos de código inicial no GitHub. A função de exemplo neste post usa Node.js 10.x.

O código do autorizador do Lambda nesta postagem usa um documento de mapeamento de permissões estático. Este documento é representado por apiPermissions. Para um documento de permissões complexo ou altamente dinâmico, esse documento pode ser desacoplado do autorizador Lambda e exportado para Amazon Simple Storage Service (Amazon S3) ou Amazon DynamoDB para gerenciamento simplificado. O documento estático contém o ARN da API implantada, o estágio do API Gateway, o recurso da API, o método HTTP e o escopo do token permitido. O autorizador do Lambda gera uma política de gerenciamento de identidade avaliando os escopos presentes no token de terceiros em relação aos presentes no documento.

O fragmento abaixo mostra um exemplo de mapeamento de permissões. Esse mapeamento restringe o acesso exigindo que os usuários que emitem solicitações HTTP GET para o ARN arn:aws:execute-api:us-east-1:219852565112:rz8w6b1ik2 e o recurso my-resource no estágio DEV API Gateway sejam permitidos apenas se fornecerem um token válido que contém o escopo do email.

# Exemplo de documento de permissão  
{  
 "arn": "arn:aws:execute-api:us-east-1:219852565112:rz8w6b1ik2",  
 "resource": "my-resource",  
 "stage": "DEV",  
 "httpVerb": "GET",  
 "scope": "email"  
}

A lógica para criar a política de gerenciamento de identidade pode ser encontrada no método generateIAMPolicy() da função Lambda. Esse método serve como um bom exemplo geral da extensão da personalização possível nos autorizadores do Lambda. Embora o método no exemplo dependa exclusivamente de escopos de token, você também pode usar informações adicionais, como contexto de solicitação, informações do usuário, endereço IP de origem, agentes do usuário e assim por diante, para gerar a política de gerenciamento de identidade retornada.

Após a chamada, o autorizador Lambda abaixo executa o seguinte procedimento:

Recebe o payload do evento de token e isola a string de token (monta “Bearer” da string de token, se presente).
Verifica o token com o provedor de identidade terceiro.Observação: essa função do Lambda não inclui essa funcionalidade. O método, VerifyAccessToken(), precisará ser personalizado com base no provedor de identidade que você está usando. Este código assume que o método VerifyAccessToken() retorna um Promise que resolve o token decodificado no formato JSON.
Recupera os escopos do token decodificado. Esse código pressupõe que esses escopos podem ser acessados como uma matriz em scp no token decodificado.
Repete os escopos presentes no token e cria declarações de política de gerenciamento de identidade e acesso (IAM) com base nas entradas no documento de mapeamento de permissões que contém o escopo em questão.
Cria uma política IAM completa e bem definida usando as declarações de política IAM geradas. Consulte Referência de elementos de política JSON do IAM para obter mais informações sobre a criação de políticas IAM de forma programática.

Retorna a política IAM completa ao API Gateway.

/* * Exemplo de Autorizador Lambda para validar tokens originários de * Provedor de identidade de terceiros e gerar uma política IAM */

const apiPermissions = [
  {
    "arn": "arn:aws:execute-api:REGION:ACCOUNTID:my-api-gw", // NOTE: Replace with your API Gateway API ARN
    "resource": "my-resource", // NOTA: Substitua por seu recurso API Gateway
    "stage": "dev", // NOTA: Substitua pelo estágio do API Gateway
    "httpVerb": "GET",
    "scope": "email"
  }
];

const defaultDenyAllPolicy = {
  "principalId":"user",
  "policyDocument":{
    "Version":"2012-10-17",
    "Statement":[
      {
        "Action":"execute-api:Invoke",
        "Effect":"Deny",
        "Resource":"*"
      }
    ]
  }
};

function generatePolicyStatement(apiName, apiStage, apiVerb, apiResource, action) {
  // Gera uma declaração de política IAM
  const statement = {};
  statement.Action = 'execute-api:Invoke';
  statement.Effect = action;
  const methodArn = apiName + "/" + apiStage + "/" + apiVerb + "/" + apiResource;
  statement.Resource = methodArn;
  return statement;
};

function generatePolicy(principalId, policyStatements) {
  // Gera uma política IAM
  const authResponse = {};
  authResponse.principalId = principalId;
  const policyDocument = {};
  policyDocument.Version = '2012-10-17';
  policyDocument.Statement = policyStatements;
  authResponse.policyDocument = policyDocument;
  return authResponse;
};

async function verifyAccessToken(accessToken) {
  /* * Verifique o token de acesso com seu provedor de identidade aqui (verifique * se seu provedor de identidade fornece um SDK). * * Este exemplo assume que este método retorna um Promise que resolve para * o token decodificado, você pode precisar modificar seu código de acordo * com a forma como seu token é verificado e o que seu provedor de identidade retorna. */
};

function generateIAMPolicy(scopeClaims) {
  // Declara a matriz de declarações de política vazia
  const policyStatements = [];
  // Itera sobre as permissões da API
  for ( let i = 0; i < apiPermissions.length; i++ ) {
  // Verifica se os escopos de token existem na permissão da API
  if ( scopeClaims.indexOf(apiPermissions[i].scope) > -1 ) {
  // Verifica se os escopos de token existem na permissão da API
  policyStatements.push(generatePolicyStatement(apiPermissions[i].arn, apiPermissions[i].stage,
    apiPermissions[i].httpVerb, apiPermissions[i].resource, "Allow"));
    }
  }
  // Verifica se o token do usuário tem escopo apropriado, adiciona permissão de API às declarações de política
  if (policyStatements.length === 0) {
    return defaultDenyAllPolicy;
  } else {
    return generatePolicy('user', policyStatements);
  }
};

exports.handler = async function(event, context) {
  // Declara Política
  let iamPolicy = null;
  // Captura o token e monta o 'Bearer', se presente
  const token = event.authorizationToken.replace("Bearer ", "");
  // Valida o token
  await verifyAccessToken(token).then(data => {
    // Obtem o token de escopo
    const scopeClaims = data.claims.scp;
    // Gera a Política IAM
    iamPolicy = generateIAMPolicy(scopeClaims);
  })
  .catch(err => {
    console.log(err);
    iamPolicy = defaultDenyAllPolicy;
  });
  return iamPolicy;
};

A seguir está um exemplo da política de gerenciamento de identidade que é retornada pela função. Se sua chamada de API contiver uma barra final, como my-resource/ em vez de my-resource, certifique-se de que sua política de gerenciamento de identidade siga a mesma sintaxe.

# Exemplo de Política IAM 
{
  "principalId": "user",
  "policyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Allow",
        "Resource": "arn:aws:execute-api:us-east-1:219852565112:rz8w6b1ik2/dev/get/my-resource"
      }
    ]
  }
}

É importante observar que o autorizador do Lambda acima não está considerando o método ou recurso que o usuário está solicitando. Isso ocorre porque você deseja gerar uma política de gerenciamento de identidade completa que contenha todas as permissões de API para o usuário, em vez de uma política que contenha apenas permitir/negar para o recurso solicitado. Ao gerar uma política completa, essa política pode ser armazenada em cache pelo API Gateway e usada se o usuário chamar uma API diferente enquanto a política ainda estiver no cache. Armazenar a política em cache pode reduzir a latência da API da perspectiva do usuário, bem como a quantidade total de invocações do Lambda; no entanto, também pode aumentar a vulnerabilidade a ataques de repetição e aceitação de tokens expirados/revogados.

Tempos de vida de cache mais curtos introduzem mais latência para chamadas de API (ou seja, o autorizador Lambda deve ser chamado com mais frequência), enquanto tempos de vida de cache mais longos introduzem a possibilidade de um token expirar ou ser revogado pelo provedor de identidade, mas ainda sendo usado para retornar uma política válida de gerenciamento de identidade. Por exemplo, o seguinte cenário é possível ao armazenar tokens em cache no API Gateway:

O provedor de identidade carimba o token de acesso com uma data de validade de 12h30.
O usuário chama o API Gateway com token de acesso às 12h29.
O autorizador do Lambda gera a política de gerenciamento de identidade e o API Gateway armazena em cache o par token/política por 5 minutos.
O usuário chama o API Gateway com o mesmo token de acesso às 12h32.
O API Gateway avalia o acesso em relação à política que existe no cache, apesar do token original ter expirado.

Como os tokens não são revalidados pelo autorizador do Lambda ou pelo API Gateway depois de colocados no cache do API Gateway, os longos tempos de vida do cache também podem aumentar a suscetibilidade a ataques de repetição. Tempos de vida de cache mais longos e grandes políticas de gerenciamento de identidade podem aumentar o desempenho de seu aplicativo, mas devem ser avaliados em relação à compensação de maior exposição a certas vulnerabilidades de segurança.

Implementando o autorizador do Lambda

Para implantar seu autorizador do Lambda, primeiro você precisa criar e implantar um pacote do Lambda contendo seu código de função e dependências (se aplicável). As funções do autorizador do Lambda se comportam da mesma forma que outras funções do Lambda em termos de implantação e empacotamento. Para obter mais informações sobre como empacotar e implantar uma função Lambda, consulte Implantar funções do Lambda em Node.js com arquivos .zip. Para este exemplo, você deve nomear sua função Lambda myLambdaAuth e usar um ambiente de tempo de execução Node.js 10.x.

Após a criação da função, adicione o autorizador do Lambda ao API Gateway.

Navegue até API Gateway e no painel de navegação, em APIs, selecione a API que você configurou anteriormente
Sob o nome da API, escolha Authorizer, em seguida, escolha Create New Authorizer.
Em Create Authorizer, faça o seguinte:
1. Em Name, insira um nome para seu autorizador Lambda. Neste exemplo, o autorizador é denominado Lambda-Authorizer-Demo.
2. Em Type, selecione Lambda
3. Para Lambda Function, selecione a região da AWS em que você criou sua função e insira o nome da função Lambda que você acabou de criar.
4. Deixe Lambda Invoke Role
5. Para Lambda Event Payload, escolha Token.
6. Para Token Source, insira Authorization.
7. Para Token Validation, insira:
```
^(Bearer )[a-zA-Z0-9\-_]+?\.[a-zA-Z0-9\-_]+?\.([a-zA-Z0-9\-_]+)$
			
```
  Isso representa uma expressão regular para validar se os tokens correspondem ao formato JWT (mais abaixo).
8. Para Authorization Caching, selecione Enabled e insira um tempo de vida (TTL) de 1 segundo.
Selecione Salvar.

Figure 2: Create a new Lambda authorizer

Figura 2: criar um novo autorizador do Lambda

Essa configuração passa o payload do evento de token mencionado acima para seu autorizador do Lambda e é necessário porque você está usando tokens (payload do evento de token) para autenticação, em vez de parâmetros de solicitação (payload do evento de solicitação). Para obter mais informações, consulte Usar os autorizadores do API Gateway Lambda.

Nesta solução, a origem do token é o cabeçalho de autorização da solicitação HTTP. Se você souber o formato esperado do seu token, poderá incluir uma expressão regular no campo Token Validation, que rejeita automaticamente qualquer solicitação que não corresponda à expressão regular. As validações de token não são obrigatórias. Este exemplo pressupõe que o token é um JWT.

# Regex correspondente ao Token JWT Bearer 
^(Bearer )[a-zA-Z0-9\-_]+?\.[a-zA-Z0-9\-_]+?\.([a-zA-Z0-9\-_]+)$

Aqui, você também pode configurar por quanto tempo o par token/política será armazenado em cache no API Gateway. Este exemplo permite o armazenamento em cache com um TTL de 1 segundo.

Nesta solução, você deixa o campo Lambda Invoke Role vazio. Esse campo é usado para fornecer uma função do IAM que permite que o API Gateway execute o autorizador do Lambda. Se deixado em branco, o API Gateway configura uma política baseada em recursos padrão que permite invocar o autorizador do Lambda.

A etapa final é apontar o recurso do API Gateway para o autorizador do Lambda. Selecione o recurso de API configurado e o método HTTP.

Navegue até API Gateway e no painel de navegação, em APIs, selecione a API que você configurou anteriormente.
Selecione o método GET.Figura 3: Execução do Método GET
Select Method Request.
Under Settings, edit Authorization and select the authorizer you just configured (in this example, Lambda-Authorizer-Demo).

Figura 4: Selecione seu autorizador de API

Implemente a API em um estágio do API Gateway que corresponda ao estágio configurado no documento de permissões do autorizador do Lambda (variável apiPermissions).

Navegue até API Gateway e no painel de navegação, em APIs, selecione a API que você configurou anteriormente.
Selecione o recurso “/” da sua API.
Selecione Actions e, em Ações de API Actions, selecione Deploy API.
Para estágio de implantação, selecione [New Stage] e, para o Stage name, insira dev. Deixe a Stage description e a Deployment description em branco.
Selecione Deploy.

Figura 5: Implemente seu estágio de API

Testando os resultados

Com o autorizador do Lambda configurado como sua fonte de autorização, agora você pode acessar o recurso somente se fornecer um token válido que contenha o escopo do e-mail.

O exemplo a seguir mostra como emitir uma solicitação HTTP com curl para seu recurso API Gateway usando um token válido que contém o escopo de e-mail transmitido no cabeçalho HTTP Authorization. Aqui, você pode autenticar e receber uma resposta apropriada do API Gateway.

# HTTP Request (incluindo um token valido com escopo "email")  
$ curl -X GET \  
> 'https://rz8w6b1ik2.execute-api.us-east-1.amazonaws.com/dev/my-resource/?myParam=myValue' \  
> -H 'Authorization: Bearer eyJraWQiOiJ0ekgtb1Z5eE...'  
  
{  
 "statusCode" : 200,  
 "message" : "Hello from API Gateway!"  
}

O objeto JSON a seguir representa a carga JWT decodificada usada no exemplo anterior. O objeto JSON captura os escopos do token em “scp” e você pode ver que o token continha o escopo do “email”.

Figure 6: JSON object that contains the email scope

Figura 6: objeto JSON que contém o escopo do e-mail

Se você fornecer um token que expirou, é inválido ou não contém o escopo do e-mail, não poderá acessar o recurso. O exemplo a seguir mostra uma solicitação para seu recurso API Gateway com um token válido que não contém o escopo do e-mail. Neste exemplo, o autorizador do Lambda rejeita a solicitação.

# HTTP Request (incluindo o token sem o escopo "email")  
$ curl -X GET \  
> 'https://rz8w6b1ik2.execute-api.us-east-1.amazonaws.com/dev/my-resource/?myParam=myValue' \  
> -H 'Authorization: Bearer eyJraWQiOiJ0ekgtb1Z5eE...'  
  
{  
 "Message" : "User is not authorized to access this resource with an explicit deny"  
}

O objeto JSON a seguir representa a carga JWT decodificada usada no exemplo acima; não inclui o escopo do e-mail.

Figure 7: JSON object that does not contain the email scope

Figura 7: Objeto JSON que não contém o escopo do e-mail

Se você não fornecer nenhum token ou fornecer um token que não corresponda à expressão regular fornecida, será imediatamente rejeitado pelo API Gateway sem invocar o autorizador do Lambda. O API Gateway apenas encaminha tokens para o autorizador do Lambda que têm o cabeçalho HTTP Authorization e correspondem a expressão regular de validação de token, se uma expressão regular foi fornecida. Se a solicitação não passar na validação do token ou não tiver um cabeçalho de autorização HTTP, o API Gateway a rejeitará com uma resposta HTTP 401 padrão. O exemplo a seguir mostra como emitir uma solicitação para seu recurso API Gateway usando um token inválido que corresponde à expressão regular que você configurou em seu autorizador. Neste exemplo, o API Gateway rejeita sua solicitação automaticamente sem invocar o autorizador.

# HTTP Request (incluindo um token que não é JWT)  
$ curl -X GET \  
> 'https://rz8w6b1ik2.execute-api.us-east-1.amazonaws.com/dev/my-resource/?myParam=myValue' \  
> -H 'Authorization: Bearer ThisIsNotAJWT'  
  
{  
 "Message" : "Unauthorized"  
}

Esses exemplos demonstram como seu autorizador do Lambda permite e nega solicitações com base no formato e no conteúdo do token.

Conclusão

Nesta postagem, você viu como os autorizadores do Lambda podem ser usados com o API Gateway para implementar um esquema de autenticação baseado em token usando tokens de terceiros.

Os autorizadores do Lambda podem oferecer vários benefícios:

Aproveite os serviços de gerenciamento de identidade de terceiros diretamente, sem federação de identidade.
Implemente a lógica de autorização personalizada.
Políticas de gerenciamento de identidade de cache para melhorar o desempenho da lógica de autorização (mantendo em mente as implicações de segurança).
Afeta minimamente os aplicativos clientes existentes.

Para organizações que buscam uma alternativa aos grupos de usuários do Amazon Cognito e aos grupos de identidades do Amazon Cognito, os autorizadores do Lambda podem fornecer serviços de autenticação e autorização completos, seguros e flexíveis para recursos implantados com o Amazon API Gateway. Para obter mais informações sobre os autorizadores do Lambda, consulte Autorizadores do Lambda do API Gateway.

Quer mais conteúdo de instruções, notícias e anúncios de recursos da AWS Security? Siga-nos no Twitter.

Este artigo foi traduzido do Blog da AWS em Inglês.

O blog da AWS