O que é autenticação HTTP?

Autenticação é um protocolo usado na comunicação HTTP para verificar a identidade de um cliente antes de conceder acesso a um recurso específico na web. É uma medida de segurança dentro do protocolo HTTP projetada para proteger usuários e empresas no ambiente online. Quando a autenticação é realizada no edge, ela melhora significativamente tanto a velocidade quanto a segurança do processo, aumentando a credibilidade e a receita de uma empresa.

Autenticação HTTP

Autenticação é um processo de controle de acesso que verifica a identidade de um cliente antes de conceder acesso a um recurso específico na web. Como resultado, a autenticação serve como uma camada adicional de segurança nas comunicações HTTP.

A requisição inicial de um cliente é tipicamente anônima, o que significa que não possui informações de identificação para confirmar a identidade do cliente. Isso pode ser arriscado, especialmente para recursos sensíveis como detalhes bancários, pois o acesso irrestrito poderia ser concedido a qualquer usuário. É aqui que a autenticação entra: para regular o acesso, o servidor nega requisições anônimas e indica que a autenticação do cliente é necessária. As informações de autenticação trocadas entre o servidor e o cliente são transmitidas por meio de cabeçalhos.

Os princípios básicos da autenticação estão descritos acima, mas como diferentes tipos de recursos exigem diferentes níveis de segurança, a complexidade da autenticação também varia. Exploraremos isso mais adiante na seção sobre esquemas de autenticação.

Como funciona a autenticação HTTP?

RFC7235 descreve como o protocolo HTTP fornece uma estrutura geral para controle de acesso e autenticação. Ele suporta um conjunto diversificado de esquemas de autenticação de desafio-resposta que permitem que um servidor desafie uma requisição do cliente e possibilite que o cliente forneça credenciais de autenticação.

O que é autenticação de desafio-resposta?

Na autenticação de desafio-resposta, o servidor emite uma solicitação — conhecida como desafio — e o cliente deve fornecer uma resposta válida para ser autenticado. Um exemplo comum de autenticação de desafio-resposta é a autenticação por senha, onde o desafio do servidor é uma solicitação de senha, e a resposta válida do cliente é a senha correta.

Cabeçalhos de autenticação

Os cabeçalhos são usados pelo servidor para definir o método de autenticação (cabeçalhos de resposta) ou pelo cliente para fornecer credenciais de autenticação (cabeçalhos de requisição). Vamos explorar como eles funcionam:

Cabeçalhos de resposta

Existem dois cabeçalhos que o servidor pode enviar: WWW-Authenticate e Proxy-Authenticate.

Ambos definem o método de autenticação que deve ser usado para que o cliente obtenha acesso a um recurso. Eles devem especificar qual esquema de autenticação usar para que o cliente que deseja autorização saiba como fornecer as credenciais.

WWW-Authenticate

O cabeçalho WWW-Authenticate indica o esquema de autenticação e os parâmetros aplicáveis ao recurso de destino.

Sintaxe: WWW-Authenticate: type realm=

Onde:

• type: é o tipo de autenticação solicitada.
• realm: é o escopo de proteção, a área a ser protegida.

Exemplo de cabeçalho WWW-Authenticate:

WWW-Authenticate: Basic realm="Access to the internal site"

Proxy-Authenticate

O cabeçalho Proxy-Authenticate define o método de autenticação que deve ser usado para obter acesso a um recurso que está atrás de um servidor proxy. Este cabeçalho consiste em pelo menos um desafio que indica o(s) esquema(s) de autenticação e parâmetros aplicáveis ao servidor proxy.

Sintaxe: ​​Proxy-Authenticate: realm=… Exemplo de cabeçalho WWW-Authenticate:

Proxy-Authenticate: Basic realm="Access to the internal site"

Cabeçalhos de requisição

O cliente pode enviar dois cabeçalhos: Authorization e Proxy-Authorization.

Ambos contêm as credenciais para autenticar o cliente com um servidor de origem ou um servidor proxy. As credenciais podem ser codificadas ou criptografadas, dependendo do esquema de autenticação usado.

Authorization

O cabeçalho Authorization permite que o cliente se autentique com um servidor de origem, geralmente após receber uma resposta 401 Unauthorized do servidor. Este cabeçalho contém credenciais com informações para autenticação do cliente para a área do recurso que está sendo solicitado.

Sintaxe: Authorization:

Onde:

• credentials: são as informações para a autenticação. Consiste no nome de usuário, seguido por dois pontos (:) e a senha do usuário. Esta sequência é então codificada com o método de codificação base64.

Nota: Base64 é um grupo de esquemas de codificação binário-para-texto semelhantes que representam dados binários em um formato de string ASCII, convertendo-o para uma representação de base 64.

Exemplo:

Se o navegador usa Azion como nome de usuário e edgecomputing como senha, o valor do campo é a codificação base64 de Azion:edgecomputing, que é QXppb246ZWRnZWNvbXB1dGluZw==. Então o cabeçalho Authorization será:

Authorization: Basic QXppb246ZWRnZWNvbXB1dGluZw==

Proxy-Authorization

O cabeçalho Proxy-Authorization permite que o cliente se autentique em um proxy, geralmente após o servidor responder com um status de 407 Proxy Authentication Required. Este cabeçalho contém credenciais com informações para autenticação do cliente no proxy e/ou na área do recurso que está sendo solicitado.

Sintaxe: Proxy-Authorization:

Exemplo de cabeçalho Proxy-Authorization:

Proxy-Authorization: Basic QXppb246ZWRnZWNvbXB1dGluZw==

Esquemas de autenticação

Basic

Como mostrado anteriormente, o servidor solicita um nome de usuário e senha em uma solicitação para autenticar um usuário em um esquema de autenticação básica. Essas informações são codificadas usando codificação base64.

Uma desvantagem da autenticação básica é que ela não é segura, por isso deve usar protocolos de segurança HTTPS/TLS para essa comunicação. Quando as informações são confidenciais ou valiosas, é necessário usar um esquema de autenticação mais seguro.

Bearer

A autenticação Bearer usa tokens de segurança chamados tokens bearer. Neste esquema, o acesso é concedido ao portador do token.

O token é uma string criptografada, geralmente gerada pelo servidor em resposta a uma solicitação de login. O cliente deve enviar esse token no cabeçalho Authorization ao solicitar acesso a recursos protegidos.

Sintaxe: Authorization: Bearer

Digest

A autenticação Digest também é baseada no mecanismo de desafio-resposta. O desafio que o servidor envia ao cliente é um valor nonce, um número aleatório que só pode ser usado uma vez. A resposta do cliente deve conter um hash com o nome de usuário, senha, valor nonce, método HTTP e URL solicitada. Este formato de hash de dados é mais complexo e dificulta o roubo e a reutilização de informações do usuário, e foi desenvolvido como uma alternativa para substituir a autenticação básica, que não é um esquema seguro.

O cliente deve enviar o hash no cabeçalho Authorization ao solicitar acesso a recursos protegidos.

Sintaxe: Authorization: Digest username=

Exemplo de autenticação Digest:

O cliente deseja ter acesso a um documento seguro por meio de uma requisição GET. O URI do documento é https://www.azion.com/pt-br/blog/. Cliente e servidor sabem que o nome de usuário para este documento é Azion e a senha é edgecomputing.

1. Na primeira vez que o cliente solicita o documento, o servidor não envia o cabeçalho de autorização e responde com:

   HTTP/1.1 401 Unauthorized

   WWW-Authenticate: Digest

   realm="registered_users@azion.com"

   qop="auth,auth-int",

   nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

   opaque="5ccc069c403ebaf9f0171e9517f40e41"

2. O cliente responderá com uma nova requisição, incluindo os seguintes cabeçalhos:

   Authorization: Digest username="Azion"

   realm="registered_users@example.com"

   nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"

   uri="blog-home"

   qop=auth

   nc=00000001

   cnonce="0a4f113b"

   response="6629fae49393a05397450978507c4ef1"

   opaque="5ccc069c403ebaf9f0171e9517f40e41"…

HTTP Origin-Bound Auth (HOBA)

A autenticação HTTP Origin-Bound (HOBA) é um esquema que não é baseado em senha, mas em assinatura. Além disso, oferece recursos adicionais como gerenciamento de credenciais e sistema de logout. Isso torna este esquema mais seguro, pois elimina o risco de vazamento de senha, já que não há banco de dados de verificação de senha do lado do servidor.

Os clientes podem se autenticar nos servidores usando o protocolo HTTP ou um programa de autenticação Javascript usando chaves público-privadas.

Sintaxe: Authorization: HOBA result="kid"."challenge"."nonce"."sig"

Onde result é a combinação dos valores kid, challenge, nonce e sig. O valor do resultado é uma string separada por pontos que inclui a assinatura e é enviada no valor do cabeçalho de autorização HTTP usando a sintaxe mostrada acima. O valor sig é a versão codificada em base64url da saída binária do processo de assinatura. Os valores kid, challenge e nonce também são codificados em base64url.

Fluxo de autenticação HOBA:

1. Para começar, o cliente determina se já possui uma chave pública para autenticação ou deve gerar uma.
2. O cliente então faz uma conexão com o servidor, antecipando que o servidor solicitará uma autenticação baseada em HOBA, que deve ser feita inscrevendo-se em um blob de informações.
3. O servidor envia um desafio que pode ser confirmado em um cabeçalho HTTP e o cliente deve responder com uma assinatura, tendo previamente fornecido ao servidor a chave pública. O servidor determina a CPK (Chave Pública do Cliente) usando o KID (Identificador de Chave) ​​para decidir se reconhece a CPK. Se a CPK for reconhecida, o processo de autenticação estará completo.

Mutual

A autenticação mútua faz a autenticação tanto do cliente quanto do servidor. Como a autenticação ocorre em ambas as direções, este esquema também é conhecido como autenticação bidirecional. Uma das características da autenticação mútua é que cliente e servidor devem fornecer certificados digitais por meio do protocolo TLS (Transport Layer Security).

Sintaxe:

O cliente envia uma requisição ao servidor com:

Authorization: Mutual user="name"

kc1="..."

O servidor responde com:

Authorization: Mutual sid=123

vkc="..."

Onde user é a string de identificação do usuário, kc1 é a chave de verificação do cliente para o servidor, sid é a chave de identificação da seção e vkc é a chave de verificação do servidor para o cliente.

Fluxo de autenticação mútua:

1. O cliente solicita um recurso sem qualquer tentativa de autenticação.
2. Se o recurso solicitado estiver protegido pelo protocolo de autenticação mútua, o servidor responderá com uma mensagem solicitando autenticação (401-INIT).
3. O cliente processa o corpo da mensagem e aguarda o usuário inserir o nome de usuário e a senha. Se o nome de usuário e a senha estiverem disponíveis, o cliente enviará uma mensagem com troca de chave autenticada (req-KEX-C1) para iniciar a autenticação.
4. O servidor procura informações de autenticação do usuário em seu banco de dados de usuários. Em seguida, cria um novo identificador de sessão (sid) que será usado para identificar conjuntos de mensagens que o seguem, e responde com uma mensagem contendo um valor de troca de chave autenticada pelo servidor (401-KEX-S1).
5. Cliente e servidor calculam um “segredo de sessão” compartilhado usando os valores trocados nas mensagens de troca de chave. Somente quando eles usam credenciais secretas geradas a partir da mesma senha é que os valores do segredo de sessão corresponderão. Este segredo de sessão será usado para autenticação de acesso de cada par individual de requisição/resposta a partir desse momento.
6. O cliente enviará uma requisição com um valor de verificação de autenticação (req-VFY-C) calculado a partir do segredo de sessão gerado pelo cliente. O servidor verificará a validade do valor de verificação usando sua própria versão do segredo de sessão.
7. Se o valor de verificação de autenticação do cliente estiver correto, o cliente possui a credencial baseada na senha esperada, ou seja, a autenticação foi bem-sucedida. O servidor responderá com uma mensagem de sucesso (200-VFY-S).

Se o valor de verificação do cliente estiver incorreto (por exemplo, porque a senha fornecida pelo usuário estava incorreta), o servidor responderá com uma mensagem 401-INIT (a mesma mensagem usada em 2).

Negotiate

A autenticação Negotiate é um mecanismo de autenticação do Microsoft Windows que usa Kerberos como seu provedor de autenticação subjacente. Kerberos funciona em um sistema de concessão de tickets para autenticar usuários em recursos e requer o uso de tokens SPNEGO GSSAPI.

Sintaxe: Authorization: Negotiate

Fluxo de autenticação Negotiate:

1. O cliente solicita acesso a um documento protegido sem qualquer tentativa de autenticação.

2. O servidor responde com:

   HTTP/1.1 401 Unauthorized

   WWW-Authenticate: Negotiate

3. O cliente obterá as credenciais do usuário usando o mecanismo SPNEGO GSSAPI para identificar e gerar uma mensagem GSSAPI que será enviada ao servidor em uma nova requisição com o cabeçalho de autorização:

   HTTP/1.1 GET dir/index.html

   Authorization: Negotiate a87421000492aa874209af8bc028

4. O servidor decodificará os dados GSSAPI e os passará para o mecanismo SPNEGO GSSAPI na função gss_accept_security_context. Se o contexto não estiver completo, o servidor responderá com um status 401 e um cabeçalho WWW-Authenticate contendo os dados GSSAPI:

   HTTP/1.1 401 Unauthorized

   WWW-Authenticate: Negotiate 749efa7b23409c20b92356

5. O cliente decodificará os dados GSSAPI, passará para gss_Init_security_context e retornará os novos dados GSSAPI para o servidor:

   HTTP/1.1 GET dir/index.html

   Authorization: Negotiate 89a8742aa8729a8b028

6. Este ciclo pode continuar até que o contexto de segurança esteja completo. Quando o valor de retorno da função gss_accept_security_context indica que o contexto de segurança está completo, ele pode fornecer dados de autenticação para serem retornados ao cliente. Se o servidor tiver mais dados GSSAPI para enviar ao cliente para completar o contexto, eles serão enviados em um cabeçalho WWW-Authenticate com a resposta final contendo o corpo HTTP:

   HTTP/1.1 200 Success

   WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca

7. O cliente decodificará os dados GSSAPI e os fornecerá a gss_init_security_context usando o contexto para este servidor. Se o status for bem-sucedido no gss_init_security_context final, a resposta poderá ser usada pela aplicação.

OAuth

A autenticação OAuth (abreviação de Open Authorization) é um protocolo de autorização de padrão aberto que permite que servidores e serviços não relacionados permitam acesso de terceiros ao recurso usando tokens de acesso em vez de compartilhar suas credenciais. Este processo também é conhecido como “acesso seguro delegado”.

Um exemplo muito simples deste esquema de autenticação é quando um usuário faz login em um site (o terceiro) e o site oferece login usando contas de outros sites/serviços, como Google ou Facebook – o que significa que você não precisa inserir suas senhas. Quando você clica no botão vinculado ao outro site, o outro site o autentica e o site ao qual você estava originalmente se conectando faz login usando a permissão obtida do segundo site.

Neste esquema, os seguintes agentes participam:

• Proprietário do recurso: entidade capaz de conceder acesso a um recurso protegido. Quando o proprietário do recurso é uma pessoa, é chamado de usuário final.
• Servidor de recursos: O servidor que hospeda os recursos protegidos. O acesso a ele é feito por meio de tokens.
• Cliente: aplicação que solicita recursos protegidos, por meio da autorização do proprietário.
• Servidor de autorização: servidor que emite tokens de acesso para o cliente, após ter sido autenticado e autorizado.

Sintaxe: Authorization: OAuth realm="Example",

oauth_consumer_key="C_KEY",

oauth_token="TOKEN",

oauth_signature_method="HMAC-SHA1",

oauth_signature="SIGNATURE",

oauth_timestamp="TS",

oauth_nonce="NONCE",

oauth_version="1.0"

Fluxo de autenticação OAuth:

1. O cliente solicita autorização do proprietário do recurso. A solicitação de autorização pode ser feita diretamente ao proprietário do recurso (como mostrado na imagem acima), ou preferencialmente indiretamente por meio da autorização do servidor como intermediário.
2. O cliente recebe uma concessão de autorização, que é uma credencial que representa a autorização do proprietário do recurso, expressa usando um dos quatro tipos de concessão definidos na especificação, ou usando um tipo de concessão de extensão. O tipo de concessão de autorização depende do método usado pelo cliente para solicitar autorização e dos tipos suportados pelo servidor de autorização.
3. O cliente solicita um token de acesso ao se autenticar com o servidor de autorização e apresentar a concessão de autorização.
4. O servidor de autorização autentica o cliente e valida a concessão de autorização e, se válida, emite um token de acesso.
5. O cliente solicita o recurso protegido do servidor de recursos e se autentica apresentando o token de acesso.
6. O servidor de recursos valida o token de acesso e, se válido, aceita a solicitação.

VAPID

A autenticação VAPID (Voluntary Application Server Identification) é projetada para permitir que sites se autentiquem com servidores de push de forma independente. Os sites podem enviar notificações push sem saber em qual navegador está sendo executado. Esta é uma melhoria significativa em relação à implementação de um protocolo de push diferente para cada plataforma.

É possível que o cliente inclua sua identidade em um token assinado com as solicitações que faz. A assinatura pode ser usada pelo serviço de push para restringir o uso de uma assinatura de push a um único servidor de aplicação.

Sintaxe: Authorization: vapid

t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczov L3B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1h aWx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_ HLGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,

k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs

Onde t é um token JWT (JSON Web Token) gerado pelo cliente e k é a chave privada (codificada em base64url) que assina este token.

O que é JSON Web Token?

Atualmente, existem muitas técnicas que podem ser implementadas para controlar o acesso a recursos online. Uma das mais comuns é o uso de algum tipo de token de acesso, gerado por aplicações para garantir que apenas usuários autenticados tenham permissão para usar certos recursos, como APIs ou arquivos de mídia. E uma dessas soluções modernas é o JSON Web Token (JWT).

Os JWTs são criptograficamente protegidos contra adulteração. Além disso, com eles, em vez de armazenar o estado do token no banco de dados, é possível codificar esse estado diretamente no ID do token e enviá-lo ao cliente. Por exemplo, você pode serializar os campos do token em um objeto JSON, codificá-lo com base64url para criar uma string que pode ser usada como o ID do token. Quando o token é apresentado de volta à API, tudo o que você precisa fazer é decodificar o token e analisar o JSON para recuperar os atributos da sessão.

Aprimorando a segurança para conteúdo restrito com JWT

A proteção de conteúdo restrito contra acesso não autorizado pode ser alcançada por meio de JSON Web Tokens (JWTs), que fornecem um método escalável e eficiente para controle de acesso. A tecnologia JWT permite autenticação segura para APIs e conteúdo privado, como vídeos, cursos online e imagens.

Os JWTs operam sem a necessidade de validação de banco de dados, tornando-os adequados para aplicações de alta performance. No entanto, como os JWTs são tipicamente maiores que os IDs de sessão, eles podem impactar a performance da rede quando incluídos em cada requisição. Executar processos de autenticação no edge ajuda a mitigar esse problema, tratando a validação mais próxima dos usuários, reduzindo a latência e garantindo um controle de acesso eficiente.

Medidas de segurança adicionais podem aprimorar ainda mais a autenticação baseada em JWT, como definir tempos de expiração para chaves e gerenciar permissões por meio de uma combinação de IDs de chave e segredos. Ao processar solicitações de autenticação no edge, a validação ocorre antes de chegar à infraestrutura de origem, eliminando a necessidade de um servidor de autenticação centralizado e melhorando tanto a segurança quanto a performance.

Essa abordagem garante que o conteúdo restrito permaneça protegido, mantendo acesso rápido e confiável para usuários autorizados.

---