O que é autenticação HTTP?

A autenticação é um protocolo utilizado na comunicação HTTP para verificar se um cliente é mesmo quem ele diz ser para que, assim, possa ter o acesso liberado a determinado recurso na web. Esse é mais um procedimento de segurança do protocolo HTTP para proteger usuários e negócios no ambiente online. E quando a autenticação é feita no edge, há um aumento significativo na velocidade e na segurança do processo e, consequentemente, na credibilidade e na receita das empresas.

Autenticação HTTP

A autenticação pode ser definida como um processo de controle de acesso, em que se verifica a identidade de um cliente para a liberação do seu acesso a determinado recurso na web. A autenticação atua, portanto, como mais uma medida de segurança nas comunicações HTTP.

Normalmente, a requisição inicial de um cliente é anônima, ou seja, não possui nenhuma informação que confirme que o cliente é quem diz ser. Isso pode ser perigoso se o recurso for mais sensível, como dados bancários por exemplo, já que o acesso estaria liberado a qualquer usuário. É aí, então, que entra a autenticação: para filtrar o acesso, o servidor nega a requisição anônima e indica que a autenticação do cliente é necessária. E as informações sobre autenticação entre servidor e cliente são enviadas por meio de headers (cabeçalhos).

Imagem com fluxo de autenticação HTTP

O que descrevemos acima são os princípios básicos da autenticação, mas como existem diversos tipos de recurso a serem acessados, a complexidade da autenticação também varia, conforme veremos mais à frente na descrição dos esquemas de autenticação.

Como funciona a autenticação HTTP?

O RFC7235 descreve que o protocolo HTTP fornece uma estrutura geral para controle de acesso e autenticação por meio de um conjunto variado de esquemas de autenticação do tipo challenge-response (desafio-resposta), que podem ser usados por um servidor para desafiar uma requisição do cliente e por um cliente para fornecer informações de autenticação.

O que é autenticação challenge-response?

Na autenticação challenge-response, o servidor faz uma solicitação – o desafio – e o cliente deve enviar uma resposta válida para ser autenticado. Um exemplo bem comum de autenticação challenge-response é a autenticação por meio de senha, em que o desafio feito pelo servidor é solicitar a senha e a resposta válida do cliente é a senha correta.

Headers de autenticação

Os headers podem ser usados pelo servidor para definir o método de uma autenticação (headers de resposta) ou para o cliente dar as credenciais para ser autenticado (headers de requisição). Vejamos como funcionam:

Headers de resposta

São dois headers que o servidor pode enviar: WWW-Authenticate e Proxy-Authenticate.

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

WWW-Authenticate

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

Sintaxe: WWW-Authenticate: type realm=<realm>

Onde:

type: é o tipo de autenticação solicitada.
realm: é usado para indicar o escopo de proteção, ou seja, a área a ser protegida.

Exemplo de header WWW-Authenticate:

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

Proxy-Authenticate

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

Sintaxe: Proxy-Authenticate: <type> realm=<realm>

Exemplo de header Proxy-Authenticate:

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

Headers de requisição

São dois headers que o cliente pode enviar: Authorization e Proxy-Authorization.

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

Authorization

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

Sintaxe: Authorization: <type> <credentials>

Onde:

credentials: são as informações para a autenticação. São formadas pelo nome de usuário, seguido de dois pontos (:) e a senha do usuário. Depois, essa sequência é codificada com o método de codificação base64.

Observação: Base64 é um grupo de esquemas de codificação binary-to-text (binário para texto) semelhantes que representam dados binários em um formato de string ASCII, convertendo-os em uma representação de radix-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, ou seja, QXppb246ZWRnZWNvbXB1dGluZw==. Então, o header Authorization será:

Authorization: Basic QXppb246ZWRnZWNvbXB1dGluZw==

Proxy-Authorization

O header Proxy-Authorization permite que o cliente se autentique para um proxy geralmente após o servidor responder com o status 407 Proxy Authentication Required. Esse header contém credenciais com as informações para a autenticação do cliente para o proxy e/ou a área do recurso que está sendo solicitado.

Sintaxe: Proxy-Authorization: <type> <credentials>

Exemplo de header Proxy-Authorization:

Proxy-Authorization: Basic QXppb246ZWRnZWNvbXB1dGluZw==

Esquemas de Autenticação

Basic

Como visto anteriormente, em um esquema de autenticação básica, o servidor solicita o nome de usuário e uma senha em uma requisição para autenticar um usuário. 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-se utilizar os protocolos de segurança HTTPS/TLS para essa comunicação. Quando as informações transmitidas forem confidenciais ou valiosas, é necessário utilizar um esquema de autenticação mais seguro.

Bearer

A autenticação Bearer, também conhecida como autenticação do portador, utiliza tokens de segurança chamados bearer tokens (tokens do portador). Nesse esquema, o acesso é dado ao portador do token.

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

Sintaxe: Authorization: Bearer <token>

Assim como a autenticação básica, a autenticação do portador também não é segura e deve ser usada com os protocolos de segurança HTTPS/TSL.

Digest

A autenticação Digest também baseia-se no mecanismo de desafio-resposta. O desafio que o servidor envia para o cliente é um valor nonce, um número aleatório que só pode ser utilizado uma única vez. A resposta do cliente deve conter um hash, com o nome de usuário, a senha, o valor nonce fornecido, o método HTTP e o URI solicitado. Esse formato com hash de dados é mais complexo e dificulta o roubo e a reutilização das 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 header Authorization ao solicitar acesso a recursos protegidos.

Sintaxe: Authorization: Digest username=<"username">

Exemplo de autenticação Digest:

O cliente quer ter acesso a um documento protegido por meio de uma solicitação GET. O URI do documento é https://www.azion.com/blog/index.html. Cliente e servidor sabem que o nome de usuário para este documento é Azion e a senha é edgecomputing.

Na primeira vez que o cliente solicita o documento, o servidor não envia o header 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"
O cliente responderá com uma nova requisição, incluindo os seguinte headers:

Authorization: Digest username="Azion"

realm="registered_users@example.com"

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"

uri="/blog/index.html"

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 digital. Além disso, oferece recursos adicionais, como gerenciamento de credenciais e sistema de logout. Isso faz esse esquema ser mais seguro, pois elimina o risco de vazamento de senhas por não haver banco de dados de verificação de senha no lado do servidor.

Os clientes podem se autenticar em servidores no protocolo HTTP ou em um programa de autenticação Javascript com o uso de chaves públicas-privadas.

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

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

Fluxo da autenticação HOBA:

Para começar, o cliente determina se já possui uma chave pública para autenticar ou deve gerar uma.
Em seguida, o cliente faz uma conexão com o servidor, antecipando que o servidor solicite a autenticação baseada em HOBA, o que deve ser feito assinando um blob de informações.
O servidor envia um desafio que pode ser confirmado em um header HTTP e o cliente deve responder com uma assinatura, tendo previamente dado ao servidor a chave pública. O servidor determina o CPK (Client Public Key, ou chave pública do cliente) usando o KID (Key Identifier, ou identificador de chave) para decidir se reconhece o CPK. Se o CPK for reconhecido, o processo de autenticação estará concluído.

Mutual

A autenticação mútua, ou Mutual, promove a autenticação tanto do cliente quanto do servidor. Como a autenticação ocorre nas duas direções, esse 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 manda para o servidor uma requisição 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 servidor para o cliente.

Fluxo da autenticação mútua:

O cliente solicita um recurso sem nenhuma tentativa de autenticação.
Se o recurso solicitado é protegido pelo protocolo de autenticação mútua, o servidor responderá com uma mensagem solicitando autenticação (401-INIT).
O cliente processa o corpo da mensagem e espera pelo usuário para inserir o nome de usuário e a senha. Se o nome de usuário e senha estão disponíveis, o cliente irá enviar uma mensagem com a troca de chave autenticada (req-KEX-C1) para iniciar a autenticação.
O servidor procura as informações de autenticação do usuário dentro de seu usuário base de dados. 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 autenticado pelo servidor (401-KEX-S1).
Cliente e servidor calculam um “segredo de sessão” compartilhado usando os valores trocados nas mensagens de troca de chaves. Apenas quando eles usam credenciais secretas geradas a partir da mesma senha que os valores secretos da sessão terão match. Esse segredo de sessão será usado para autenticação de acesso de cada par de requisição/resposta individual após esse momento.
O cliente enviará um pedido com um valor de verificação de autenticação (req-VFY-C), calculado a partir do segredo de sessão gerado por ele. O servidor irá verificar a validade do valor de verificação usando sua própria versão do segredo da sessão.
Se o valor de verificação de autenticação do cliente estiver correto, o cliente possui a credencial com base 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 que a 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. O Kerberos funciona em um sistema de concessão de tickets para autenticar usuários em recursos e exige o uso de tokens SPNEGO GSSAPI.

Sintaxe: Authorization: Negotiate <gssapi-data>

Fluxo da autenticação Negotiate:

O cliente solicita o acesso a um documento protegido sem nenhuma tentativa de autenticação.
O servidor responde com:

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Negotiate
O cliente obterá as credenciais do usuário usando o mecanismo SPNEGO GSSAPI para identificar e gerar uma mensagem GSSAPI que será enviada para o servidor em uma nova requisição com o header de autorização:

HTTP/1.1 GET dir/index.html

Authorization: Negotiate a87421000492aa874209af8bc028
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 header WWW-Authenticate contendo os dados GSSAPI:

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Negotiate 749efa7b23409c20b92356
O cliente decodificará os dados GSSAPI, passá-los para gss_Init_security_context e retornar os novos dados GSSAPI para o servidor:

HTTP/1.1 GET dir/index.html

Authorization: Negotiate 89a8742aa8729a8b028
Esse ciclo pode continuar até que o contexto de segurança seja concluído. 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 a serem devolvidos ao cliente. Se o servidor tiver mais dados GSSAPI para enviar ao cliente para completar o contexto, será enviado em um header WWW-Authenticate com a resposta final contendo o corpo HTTP:

HTTP/1.1 200 Success

WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca
O cliente irá decodificar os dados GSSAPI e fornecê-lo para gss_init_security_context usando o contexto para este servidor. Se o status é bem-sucedido no gss_init_security_context final, a resposta pode ser usada pela aplicação.

OAuth

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

Um exemplo bem simples desse esquema de autenticação é quando um usuário vai fazer login em um site e esse site oferece fazer login usando contas de outros sites/serviços, como Google ou Facebook – ou seja, você não precisa inserir suas senhas. Ao clicar no botão vinculado ao outro site, o outro site autentica você e o site ao qual você estava se conectando originalmente faz login usando a permissão obtida no segundo site.

Nesse esquema, participam os seguintes agentes:

Dono do recurso (Resource owner): entidade capaz de conceder acesso a um recurso protegido. Quando o proprietário do recurso é uma pessoa, é chamado de end-user.
Servidor do recurso (Resource server): o servidor que hospeda os recursos protegidos. O acesso a ele é feito através de tokens.
Cliente (Client): aplicação que requisita recursos protegidos, através da autorização do dono.
Servidor de autorização (Authorization server): servidor que emite tokens de acesso ao cliente, depois de sua autenticação e obtenção de autorização.

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 da autenticação OAuth:

O cliente solicita autorização ao proprietário do recurso. A requisição de autorização pode ser feita diretamente ao proprietário do recurso (conforme mostrado na imagem acima), ou de preferência indiretamente por meio da autorização do servidor como intermediário.
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 os tipos suportados pelo servidor de autorização.
O cliente solicita um token de acesso ao autenticar com o servidor de autorização e apresentar a concessão de autorização.
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.
O cliente solicita o recurso protegido ao servidor do recurso e autentica apresentando o token de acesso.
O servidor do recurso valida o token de acesso e, se for válido, atende ao pedido.

Vapid

A autenticação VAPID (Voluntary Application Server Identification) foi criada para permitir que sites se autentiquem com servidores de push de maneira independente do fornecedor. Os sites podem enviar notificações por push sem saber o navegador no qual ele está sendo executado. Essa é 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 requisições que ele faz. A assinatura pode ser usada pelo serviço push para restringir o uso de uma assinatura push a um único servidor de aplicações.

Sintaxe: Authorization: vapid

t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_HLGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,

k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs

Onde t é um token JWT (JSON Web Token) gerado pelo cliente e k é a chave privada (codificado com base64url) que assina esse token.

O que é JSON Web Token?

Atualmente, existem muitas técnicas que podem ser implementadas no controle de acesso a recursos online. Uma das mais comuns é a utilização de algum tipo de token de acesso, gerados por aplicações para garantir que somente usuários autenticados tenham permissão de utilizar determinados recursos, como por exemplo APIs ou arquivos de mídias. 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, é possível serializar os campos de 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, só é preciso decodificar o token e analisar o JSON para recuperar os atributos da sessão.

Você quer mais segurança para proteger conteúdo restrito contra acessos indevidos?

Isso é possível com o Azion JWT, a solução de access token da Azion.

Com o Azion JWT, você fornece mais segurança para seus conteúdos e APIs. Por ser executada diretamente no edge da rede, essa é uma solução robusta e eficaz para o controle de acesso e conteúdo fechado ou personalizado, tais como vídeos, aulas, imagens ou APIs.

Nesse processo, a Azion utiliza JSON Web Tokens (JWTs), um tipo de token que pode ser validado sem que seja necessário consultar uma base de dados, facilitando a escalabilidade dos serviços. Entretanto, muitas vezes o tamanho de um JWT excede o de um ID de sessão, podendo afetar a performance da rede, visto que ele deve ser incluído em todas as requisições. Mas como nossa solução é em edge computing, além de resolver esse problema, agregamos funcionalidades adicionais de segurança, como fornecer e revogar permissões através da combinação de Key IDs e secrets, além de determinar tempo de expiração para essas chaves.

Além disso, por rodar dentro dos edge nodes da Azion, mais próximo dos usuários, o Azion JWT valida a autenticidade das requisições antes mesmo que elas cheguem à sua infraestrutura, sem a necessidade de consultar um servidor de autenticação específico para validar as credenciais do token passado nas requisições, proporcionando mais velocidade ao processo e segurança para seu negócio.

Você quer o Azion JWT para proteger o seu conteúdo e os seus clientes? Fale com um de nossos especialistas aqui.