Lambdas AWS de autorização
Continuando nossa série sobre Lambdas AWS, nesse post eu vou falar um pouquinho sobre o que são e como funcionam Lambdas AWS de autorização, e dar alguns exemplos de como as utilizamos aqui na Legiti.
Caso você não tenha visto os últimos artigos, recomendo dar uma olhadinha neles antes de começar este aqui:
O que é um autorizador?
Antes de uma requisição ser direcionada para um determinado endpoint, o API Gateway pode acionar uma Lambda de autorização, que então define se deve ser concedido acesso ao usuário ou não. Esse autorizador é apenas uma função AWS Lambda como todas as demais, portanto podemos adicionar qualquer lógica de autenticação ou autorização que for relevante para nosso sistema, e ela será executada antes de a requisição chegar ao endpoint de destino.
A principal vantagem de utilizar um autorizador é a de que ele desacopla completamente a lógica de autenticação/autorização da lógica de negócio, permitindo que o mesmo autorizador seja utilizado para diferentes endpoints. Esse desacoplamento permite que mudanças no sistema de autorização sejam aplicadas sem intervenção nos serviços que estão atrás desse autorizador.
Como funciona?
Fonte: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
- O usuário envia uma requisição para a API;
- O API Gateway automaticamente aciona o autorizador associado ao endpoint;
- O autorizador então checa as credenciais enviadas. Isto pode ocorrer de maneiras distintas: ele pode validar um token, checar através de um third-party identity provider se é um usuário válido, etc…
- Após a checagem, o autorizador deve gerar um documento com uma política IAM, que, de maneira bem simplificada, consiste em um JSON, que indica se o acesso deve ser autorizado ou negado. Essa política IAM é colocada em um cache, e então enviada ao API Gateway como resposta.
- O API Gateway avalia a política IAM, e então, temos duas possiblidades:
- Caso seja verificado que o acesso ao recurso solicitado pelo usuário foi autorizado, a requisição é direcionada para o recurso solicitado.
- Se o acesso for negado, o API Gateway retorna uma resposta ao usuário com o código 403 (ACCESS_DENIED)
Exemplo de utilização
Tomando nosso caso como exemplo, nós utilizamos tokens JWT para fazer a autenticação de nossos usuários. Esses tokens são validados durante a execução do nosso autorizador, que se encontra à frente dos nossos serviços de avaliação de pedidos e de coleta de dados.
Uma feature bastante útil que usamos para fazer testes com nossas APIs é a adição de prefixos aos tokens, que indicam qual fluxo uma requisição deve seguir em nossos serviços:
— live: indica que é uma requisição real, vinda de algum de nossos usuários;
— sandbox: indica que é uma requisição de sandbox, geralmente utilizado em etapas de iniciais de integração para checar se os dados que estão nos enviando estão de acordo com o esperado;
— internal: usados por nós para simular requisições reais, permitindo que elas sigam todo o caminho que uma requisição live seguiria, porém, salvando os dandos de maneira a deixar explícito de que foi uma requisição de teste.
A utilização desses prefixos é possível, pois durante a execução do autorizador, nós adicionamos um pequeno trecho de código onde removemos o prefixo antes de validarmos o token, (caso contrário, o token seria considerado inválido), e então, após validado, o adicionamos novamente para que o serviço destino possa utilizar essa informação.
Para finalizar, vou deixar aqui a documentação para configurar um autorizador tanto pelo console da AWS, quanto pelo arquivo de configuração do Serverless Framework.
Aqui encerramos nossa minissérie de artigos sobre funções AWS Lambda! Espero que essas informações tenham ajudado um pouco a trazer alguns exemplos práticos de como criar e configurar APIs usando funções AWS Lambda.
E, como sempre, estou à disposição para quaisquer dúvidas! Até mais :)
