Como lidar com a autenticação em uma arquitetura RESTful Client-Server é uma questão de debate.
Geralmente, isso pode ser alcançado no mundo SOA sobre HTTP via:
- Autenticação básica HTTP sobre HTTPS;
- Gerenciamento de cookies e sessões;
- Token em cabeçalhos HTTP (por exemplo, OAuth 2.0 + JWT);
- Autenticação de consulta com parâmetros de assinatura adicionais.
Você terá que se adaptar, ou ainda melhor, misturar essas técnicas, para combinar com sua arquitetura de software, na melhor das hipóteses.
Cada esquema de autenticação possui seus próprios PROs e CONs, dependendo do objetivo da sua política de segurança e arquitetura de software.
Autenticação básica HTTP sobre HTTPS
Essa primeira solução, baseada no protocolo HTTPS padrão, é usada pela maioria dos serviços web.
GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
É fácil de implementar, disponível por padrão em todos os navegadores, mas possui algumas desvantagens conhecidas, como a terrível janela de autenticação exibida no Navegador, que persiste (não há recurso semelhante ao LogOut aqui), algum consumo adicional de CPU no servidor, e o fato de o nome de usuário e a senha serem transmitidos (via HTTPS) para o servidor (deve ser mais seguro permitir que a senha permaneça apenas no lado do cliente, durante a entrada do teclado e seja armazenada como hash seguro no servidor) .
Podemos usar a autenticação Digest , mas também requer HTTPS, pois é vulnerável a ataques MiM ou Replay e é específico para HTTP.
Sessão via Cookies
Para ser sincero, uma sessão gerenciada no servidor não é verdadeiramente sem estado.
Uma possibilidade poderia ser manter todos os dados no conteúdo do cookie. E, por padrão, o cookie é manipulado no lado do servidor (o cliente, na verdade, nem tenta interpretar esses dados do cookie: apenas o devolve ao servidor a cada solicitação sucessiva). Mas esses dados do cookie são dados do estado do aplicativo, portanto, o cliente deve gerenciá-los, não o servidor, em um mundo sem Estado puro.
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
A técnica do cookie em si é vinculada ao HTTP, portanto, não é verdadeiramente RESTful, que deve ser independente do protocolo, IMHO. É vulnerável a ataques MiM ou Replay .
Concedido por token (OAuth2)
Uma alternativa é colocar um token nos cabeçalhos HTTP para que a solicitação seja autenticada. É isso que o OAuth 2.0 faz, por exemplo. Veja o RFC 6749 :
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Em resumo, isso é muito semelhante a um cookie e sofre os mesmos problemas: não estático, depende de detalhes de transmissão HTTP e está sujeito a muitas deficiências de segurança - incluindo MiM e Replay -, portanto, deve ser usado apenas por HTTPS. Normalmente, um JWT é usado como um token.
Autenticação de consulta
A autenticação de consulta consiste em assinar cada solicitação RESTful por meio de alguns parâmetros adicionais no URI. Veja este artigo de referência .
Foi definido como tal neste artigo:
Todas as consultas REST devem ser autenticadas assinando os parâmetros de consulta classificados em ordem alfabética minúscula, usando a credencial privada como o token de assinatura. A assinatura deve ocorrer antes do URL que codifica a string de consulta.
Essa técnica é talvez a mais compatível com uma arquitetura Stateless e também pode ser implementada com um gerenciamento de sessões simples (usando sessões na memória em vez de persistência de banco de dados).
Por exemplo, aqui está uma amostra de URI genérica no link acima:
GET /object?apiKey=Qwerty2010
deve ser transmitido como tal:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
A cadeia de caracteres assinada é /object?apikey=Qwerty2010×tamp=1261496500e a assinatura é o hash SHA256 dessa cadeia de caracteres usando o componente privado da chave da API.
O cache de dados do servidor pode estar sempre disponível. Por exemplo, em nossa estrutura, armazenamos em cache as respostas no nível SQL, não no URI. Portanto, adicionar esse parâmetro extra não quebra o mecanismo de cache.
Consulte este artigo para obter alguns detalhes sobre autenticação RESTful em nossa estrutura ORM / SOA / MVC cliente-servidor, com base em JSON e REST. Como permitimos a comunicação não apenas por HTTP / 1.1, mas também por pipes nomeados ou mensagens GDI (localmente), tentamos implementar um padrão de autenticação verdadeiramente RESTful e não dependemos da especificidade do HTTP (como cabeçalho ou cookies).
Nota posterior : adicionar uma assinatura ao URI pode ser considerado uma má prática (uma vez que, por exemplo, aparecerá nos logs do servidor http), pelo que deve ser mitigado, por exemplo, por um TTL adequado para evitar replays. Mas se seus logs http estiverem comprometidos, você certamente terá maiores problemas de segurança.
Na prática, a próxima autenticação de token MAC para OAuth 2.0 pode ser uma grande melhoria em relação ao esquema atual "Granted by Token". Mas este ainda é um trabalho em andamento e está vinculado à transmissão HTTP.
Conclusão
Vale a pena concluir que o REST não é apenas baseado em HTTP, mesmo que, na prática, ele também seja implementado principalmente por HTTP. O REST pode usar outras camadas de comunicação. Portanto, uma autenticação RESTful não é apenas sinônimo de autenticação HTTP, independentemente do que o Google responder. Ele nem deve usar o mecanismo HTTP, mas deve ser abstraído da camada de comunicação. E se você usar a comunicação HTTP, graças à iniciativa Let's Encrypt, não há razão para não usar HTTPS adequado, necessário além de qualquer esquema de autenticação.