Escolhendo um authorizer do API Gateway

Usando a segurança da AWS para desenvolvedores

Rahul Singh

Technical Product Manager

Checado antes do seu código rodar

Uma chamada passa pelo authorizer do API Gateway antes de chegar ao seu código; quem é rejeitado recebe 401.

Passa: a requisição chega ao seu código

Falha: 401 unauthorized, seu código não roda

Quem faz a checagem

Três authorizers para escolher

IAM auth (AWS_IAM): a AWS checa uma assinatura

Uma pilha vertical em um eixo indo de a AWS fazendo a checagem até você fazendo. Só o primeiro cartão está preenchido: IAM auth, onde a AWS checa uma assinatura.

Quem faz a checagem

Três authorizers para escolher

IAM auth (AWS_IAM): a AWS checa uma assinatura
Cognito authorizer (COGNITO_USER_POOLS): a AWS verifica um token
- Assinatura, iss, aud, exp

A mesma pilha vertical com dois cartões preenchidos: IAM auth, onde a AWS checa uma assinatura, e um Cognito authorizer, onde a AWS verifica um token.

Quem faz a checagem

Três authorizers para escolher

IAM auth (AWS_IAM): a AWS checa uma assinatura
Cognito authorizer (COGNITO_USER_POOLS): a AWS verifica um token
- Assinatura, iss, aud, exp
Lambda authorizer: sua função retorna allow ou deny
- Para tokens que não são do Cognito

Três authorizers ranqueados de a AWS fazendo a checagem até você fazendo: IAM auth onde a AWS checa uma assinatura, um Cognito authorizer onde a AWS verifica um token, e um Lambda authorizer onde você escreve a checagem.

Combine a porta com quem chama

Quem chama decide

Serviço interno: já tem credenciais da AWS

A primeira de três linhas mapeando chamador→authorizer: um serviço interno mapeado para IAM auth.

Combine a porta com quem chama

Quem chama decide

Serviço interno: já tem credenciais da AWS
Usuário do app: carrega um token do Cognito

Duas de três linhas chamador→authorizer: um serviço interno mapeado para IAM auth e um usuário de app mapeado para um Cognito authorizer.

Combine a porta com quem chama

Quem chama decide

Serviço interno: já tem credenciais da AWS
Usuário do app: carrega um token do Cognito
App parceiro: traz sua própria lógica de autorização

Três chamadores mapeados para o authorizer de que precisam: serviço interno → IAM auth, usuário de app → Cognito authorizer, app parceiro → Lambda authorizer.

Atenção ao tipo de API

REST API

Todos os três authorizers, mais policies de recurso
Chaves de API, throttling por cliente, validação de requisição, WAF

Um cartão de comparação para REST API, marcando IAM auth, Cognito user pool authorizer, Lambda authorizer e resource policy. O cartão de HTTP API ao lado ainda não está preenchido.

Atenção ao tipo de API

REST API

Todos os três authorizers, mais policies de recurso
Chaves de API, throttling por cliente, validação de requisição, WAF

HTTP API

JWT authorizer, qualquer emissor OIDC
Sem policies de recurso; mais barata e rápida

Dois cartões comparando quais authorizers cada tipo de API suporta: uma REST API adiciona resource policies, enquanto uma HTTP API troca o Cognito authorizer por um JWT authorizer e não tem resource policies.

O authorizer lembra

Com cache para ganhar tempo

Primeira chamada: o authorizer roda
Chamadas seguintes: lê a resposta em cache

A primeira chamada roda o authorizer e grava um allow em um cache com tempo de vida; depois, outra chamada lê esse allow do cache sem rodar o authorizer de novo.

O authorizer lembra

Com cache para ganhar tempo

Primeira chamada: o authorizer roda
Chamadas seguintes: lê a resposta em cache

TTL do cache

authorizerResultTtlInSeconds: padrão 300s, máximo 3600s
Zero desativa o cache

A primeira chamada roda o authorizer e grava um allow em um cache com tempo de vida; depois, outra chamada lê esse allow do cache sem rodar o authorizer de novo.

Um allow em cache pode sobreviver à permissão

Uma linha do tempo com duas faixas. A faixa de permissão muda de válida para revogada no ponto de revogação, enquanto a faixa de allow em cache abaixo ainda mostra allow após esse ponto, com a janela após a revogação sombreada.

No momento da revogação

Permissão: revogada na hora
Allow em cache: ainda concedendo

Um allow em cache pode sobreviver à permissão

A mesma linha do tempo com a janela entre a revogação e o vencimento do TTL sombreada e marcada ainda permitido, onde a permissão está revogada mas o allow em cache segue concedendo acesso.

A janela no meio

Permissão caiu, cache não foi avisado
Acesso dura até o TTL expirar

Um allow em cache pode sobreviver à permissão

A mesma linha do tempo com uma seta pela janela sombreada mostrando que um TTL menor antecipa o vencimento e encolhe o período em que uma permissão revogada ainda concede acesso.

Controle essa janela

TTL curto quando a revogação precisa ser rápida
TTL 0 nas rotas mais sensíveis

Um chamador pula a porta da frente

Um terceiro dentro da sua conta

Assume uma role que você criou
Você entrega o ARN da role

Um fornecedor de monitoramento fica entre duas caixas de clientes acima e sua role abaixo. Sua caixa entrega o ARN da role ao fornecedor, que assume sua role. A segunda caixa de cliente está apagada e ainda fora da história.

Um chamador pula a porta da frente

Um terceiro dentro da sua conta

Assume uma role que você criou
Você entrega o ARN da role

O ARN da role não é segredo

O problema do "deputy" confuso

A segunda caixa de cliente agora está ativa em vermelho e entrega o seu ARN da role como se fosse dela. Duas setas vão do fornecedor de monitoramento até sua role, uma chamada por cliente, e nada as diferencia.

Um chamador pula a porta da frente

Um terceiro dentro da sua conta

Assume uma role que você criou
Você entrega o ARN da role

O ARN da role não é segredo

O problema do "deputy" confuso

A correção: sts:ExternalId

O fornecedor gera um por cliente
Sua trust policy exige a correspondência

Sua role agora exige que o external ID seja igual a 12345. A chamada com 12345 chega à role, e a chamada com 99999 é barrada por um X vermelho antes de chegar.

Vamos praticar!

Usando a segurança da AWS para desenvolvedores