Please enable JavaScript.
Coggle requires JavaScript to display documents.
Autenticação e Autorização - Coggle Diagram
Autenticação e Autorização
OAuth 2.0
4 agentes que participam da autorização e acesso
Resource Owner
usuário ou aplicativo que possui o recurso que precisa ser acessado (ex.: Google Drive)
OAuth Server
servidor que autentica o proprietário do recurso e concede permissões de acesso ao aplicativo solicitante, verificando a identidade do usuário e validando as credenciais de acesso
Client
serviço que quer ter acesso ao outro. Deve ter uma identificação exclusiva
Resource Server
é o servidor que hospeda o recurso protegido. Ele é quem verifica se o aplicativo tem permiss"ao para acessar o recurso
Principal conjunto de recursos e ferramentas que permitem que alguém autorize um terceiro a acessar seus recursos. Foco em
Autorização
Ao contrário do OAuth 1.0 que foi projeto somente para autenticação via token, o 2.0 suporta com ou sem token (Access token)
Tokens
id_token:
usado para autenticar o usuário e fornecer informações sobre ele. Prova que o usuário foi autenticado.Não é usado para acessar APIs protegidas, pois ele apenas contém informações de autenticação e não concede permissões para acessar recursos. Geralmente é exposto para que o cliente possa acessar informações sobre o usuário.
access_token
: token que representa a autorização para acessar algo (inclui as roles). É o mais utilizado para a comunicação com o identity server. Normalmente já possui as informações do usuário. É enviado para aplicações protegidas no cabeçalho
Authorization: Bearer <access_token>
. Têm um tempo de vida curto (até 60min). Deve ser armazenado em cookies HTTP-only. deve ser mantido seguro, mas pode ser incluído em requisições para APIs
scope
determina o conjunto de informações aos quais eu terei acesso
refresh_token
é usado para obter novos Access Tokens sem exigir que o usuário se autentique novamente. É emitido junto com o
access token
mas tem um tempo de vida um pouco maior. É armazenado no client, mas deve ser com segurança. Dura dias. Deve ser armazenado em cookies HTTP-only. deve ser mantido muito seguro e nunca exposto diretamente ao cliente ou incluído em requisições a APIs externas
Fluxos
authorization-code
é um código temporário emitido pelo servidor de autorização após o usuário ser autenticado. É utilizado para obter o acces e Id otken em uma etapa posterior. Enviado via redirecionamento em HTTPS. Bom para backend
Principais tipos de ataques no
autorization-code
CSRF attack (Cross-Site Request Forgery)
é um ataque que força um usuário autenticado em um site a executar ações não intencionais em outro site no qual ele possui privilégios. Ex.: ele loga de forma legítima no site do banco, daí o atacante envia outro endereço com um script que faz alguma transação. Como ele já está logado e os cookies estão no browser, a operação é executada sem ele saber
Replay attack
atacante replica a chamada de callback pós envio authorization-code para pegar os tokens. Para proteger, utilizar o
Nonce
(Number used once), que é um número aleatório gerado no início do processo de login. Esse número fica no id e no access token. Daí se ele gerar outra requisição vai ter outro nonce
Implicit flow
ao invés de receber o
authorization-code
primeiro para depois pegar os tokens, ele já envia os tokens na URL (mas é um risco de segurança, logo recomendado para ambientes internos). Feito apenas para frontend
Hybrid flow
também para front, ele retorna o código de autorização e o ID/Access token "iniciais" (já estou autenticado no front e ganho em performance). Depois eu envio o authorization code para pegar o access token e o id token finais
Resource Owner Password Credentials ou Direct Grant
A própria aplicação tem sua tela de login ao invés de ser redirecionado. Ao informar o usuário e senha é enviada uma requisição HTTP para o servidor de identidade. Após autenticar, retorna o access token. Nas chamadas seguintes os requests são feitos com o access token, que uma vez que o servidor recebe e valida, devolve o recurso. Bom quando quero realizar algumas operações durante a autenticação, tenho mais controle. Não suporta autenticação por dois fatores ou login social. Não tem SSO. Vale para o backend
Principal referência: RFC6749
Open ID Connect
Camada de autenticação baseada em token sobre o protocolo OAuth 2.0. Foi criado para fornecer autenticação federada para aplicativos web e móveis,
permitindo que os usuários façam login em diferentes aplicativos usando as credenciais de uma única identidade
(ex.: autentiquei no Drive e depois já entro no Google - SSO)
Ele acrescenta a Autenticação no OAuth 2.0 (acrescenta o token JWT - ID Token)
Mecanismos de Autenticação
JWT (JSON Web Tokens)
Com a chave pública eu consigo confirmar a autenticidade do token sem precisa-lo decodifica-lo
É um token compacto, URL-safe, auto-contido utilizado para transmitir informações seguras entre as partes. Habilita conexões stateless, contendo todas as informações necessárias
3 partes:
Header, Payload e Signature
. Os dois primeiros são criptografados por um Base64
Payload
contém os claims, que são informações sobre o usuário ou o token. Podem ser
Registered Claims
predefinidas como iss (issuser), exp (expiration time), subj (subject),
Public claims
customizadas, definidas pela aplicação e
Private claims
compartilhadas entre issuser e consumer
Signature
garante a integridade do token e verifica a autenticidade do remetente. É criado pela codificação do header e do payload e assinando com um certificado ou chave privada
Header
que contém o medatado sobre o token, incluindo o tipo (JWT) e o algoritmo de assinatura
Fluxo
após autenticar o usuário, o servidor gera o token JWT contendo as claims do usuário, criptografa de forma simétrica ou assimétrica e o devolve par ao cliente via response body ou cookie. Quando o cliente o envia em seus requests, o servidor valida a assinatura, checa expiração (exp) e audiência (aud)
(+) Escalabilidade, já que não precisa de um armazenamento central. Compacto e portável, uma vez que o Base64 permite que o JWT seja facilmente transmitido nos cabeçalhos HTTP ou cookies. Útil para SSO e seguro
(-) Se roubado (ex. via XSS) pode ser utilizado até expirar. Pode ser mitigado por HTTPS e/ou HTTP Only cookies. Necessidade de uma gestão de expiração, através de refresh tokens para evitar a necessidade de novos logins. Tokens muito grandes afetam performance. Nós não conseguimos revogar diretamente um token
Cookies
pedaços de dados armazenados no browser do cliente pelo we server. Eles permitem o controle de sessão, promover personalização e registrar o histórico do comportamento
(+) Suportados pela maioria dos browsers. Podemos ter controle de expiração. São enviados automaticamente em cada request pelo browser e já possuem customizações como HttpOnly, Secure e SameSite para aumentar a segurança.
(-) Bowsers impõem limites de tamanho (4KB por cookie) e de quantidade por domínio. Muitos cookies podem reduzir a performance
Possíveis ataques
XSS Cross Site Scripting
quando script malicioso é injetado no website e libera o acesso aos dados do mesmo. Para previnir utilizar a flag HttpOnly
Main-in-the-middle (MITM)
se o cookie for transmitido em um HTTP sem encriptação pode ser interceptado e roubado. Setando a flag Secure garante que ele só seja enviado via HTTPS
Cross-Site Request Forgery (CSRF)
cookies podem ser explorados para performar ações não autorizadas. Para mitigar, você pode implementar o CSRF token e usar o atributo SameSite
Sessions
mecanismo do lado do servidor utilizado para armazenar os dados de autenticação do usuário. Nesse caso o client armazena apenas a
sessionID
em memória ou banco de dados. O client manda o sessionID em todos os seus requests, normalmente via cookie. A sessionID é removida no momento em que o cliente desloga
(+) armazenamento seguro, uma vez que fica no servidor, evitando exposições de XSS, etc. Os dados de sessão podem ser complexos (dados, roles, permissions, preferences, etc), podem ser invalidados no servidor, podendo terminar imediatamente.
(-) Escalabilidade, onde necessita de um servidor para centralizar as sessões para servir aos microsserviços distribuídos. Ataque de
session hijacking
onde o atacante pode roubar a sessionID em uma request não HTTPS.
PASETO
Conceitos básicos
Acrónimo de Platform-Agnostic Security Tokens, que endereça algumas dificuldades do JWT
3 diferenças para o JWT
força o uso de algoritmos de criptografia mais modernos, tem design mais simples, mais seguro (encriptação e assinatura) e foi desenvolvido para eliminar algumas vulnerabilidades do JWT
Componentes
Version
indica a versão do protocolo PASETO que está sendo utilizada.
Propósito
especifica o tupo de token (encriptado-local ou assinado-public)
Payload
dados e claims do usuário
Footer
metados opcionais, como audience (aud) ou issuer (iss)
Conceitos básicos
Autenticação
processo de verificação da identidade de um usuário, device ou sistema tentando acessar uma aplicação. Confirma se a pessoa é quem ela diz ser. Inclui validar username, password, dados biométricos ou tokens
Autorização
determina as permissões e os níveis de acesso que o usuário autenticado tem
Referências
Full Cycle
https://blog.bytebytego.com/p/mastering-modern-authentication-cookies?utm_source=substack&publication_id=817132&post_id=152593729&utm_medium=email&utm_content=share&utm_campaign=email-share&triggerShare=true&isFreemail=false&r=39wa04&triedRedirect=true
Boas práticas
Utilize HTTPS em todos os ambientes, redirecionando eventuais requests HTTP para ele e utilizando versões TLS fortes (TLS 1.2 ou 1.3)
Utilize políticas fortes de senhas
Implemente MFA, como TOTP via Google Authenticator, SMS OTP, push notifications para MFA
Tokens
. Utilize tokens com pequeno TTL (exp claim), refresh tokens, cookies HttpOnly e revogue-os se necessário
Utilizar as flags para aumentar a segurança dos cookis como HttpOnly, Secure, SameSite
CORS
Faz parte das políticas
Same-Origin Policy (SOP)
que através de cabeçalhos HTTP declare explicitamente quais origens têm permissão para acessar seus recursos.
Utilizado uma vez que um aplicativo pode precisar que um site
https://frontend.com
acesse uma api em
https://api.backend.com
(o mais simples seria todos dentro do mesmo domínio, ex:
https://dominio.com
e
https://dominio.com/api
. Ex.: Frontend e Backend em domínios diferentes, APIs públicas, integração entre microsserviços
Tipos de Requisições
Simple Requests
que não exigem validação extra pelo navegador, nem cabeçalhos customizados. Apenas para GET, POST ou HEAD
Preflight Requests
para PUT, DELETE ou cabeçalhos customizados, o navegador envia uma requisição preliminar OPTIONS ao servidor para verificar se a operação é permitida
Requisições com Credenciais
para enviar cookies ou cabeçalhos de autenticação (
Authorization
) o servidor deve permitir o cabeçalho
Access-Control-Allow-Credentials: true
Principais cabeçalhos na resposta do servidor
Access-Control-Allow-Origin
especifica quais orgiens têm permissão para acessar o recurso: ex.
https://frontend.com
Access-Control-Allow-Methods
especifica os métodos HTTP permitidos: GET, POST, PUT
Access-Control-Allow-Headers
lista os cabeçalhos que podem ser usados na requisição:X-Custom-Header, Authorization
Access-Control-Allow-Credentials
permite o envio de cookies ou cabeçalhos de autenticação
Access-Control-Max-Age
define por quanto tempo o navegador pode armazenar a resposta da requisição em cache. Ex. 86400
Expose headers (cabeçalho Access-Control-Expose-Headers)
Cabeçalhos utilizados para permitir que certos cabeçalhos sejam acessíveis pelo JavaScript no navegador, após uma requisição ser feita em outra origem usando CORS
Necessário, pois os navegadores restringem o acesso à apenas um conjunto limitado de cabeçalhos nesse contexto.
Uso
para expor cabeçalhos como
Authorization ou WWW-Authenticate
para que o cliente possa gerenciar os tokens. Para APIs que retornam cabeçalhos de paginação como
X-Total-Count ou X-Next-Page
. Para expor cabeçalhos ligados a rate limiting (X-RateLimit-Remaining)