Por que precisamos da segurança do serviço REST se temos HTTPS

Refiro-me a este excelente artigo http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/, que fala da amazônia como segurança para serviços da web. No entanto, uma pergunta na equipe me fez perguntar por que precisamos dela se já usamos HTTPS. Eu não consegui responder, pois realmente me parece que eles podem estar certos, embora o intestino me diga o contrário.

Também há lugares ao fornecer serviços REST em que o HTTPS pode não funcionar? Gosta de sites de terceiros?

Se alguém tiver experiência em proteger serviços da Web por meio de interwebs públicas, lembre-se de sua experiência.

Desde já, obrigado.

EDIT: Para esclarecer, não estou falando de autenticação de usuário, mas mais de autenticação de cliente. A autenticação do usuário pode ser assumida como texto sem formatação sobre HTTPS + REST.

Minha preocupação é que isso ainda permita que qualquer pessoa use o serviço da Web sem o meu cliente para acessá-lo, pois tudo é um texto simples, embora por HTTPS o ponto final do cliente ainda possa usar o meu serviço da Web sem o aplicativo cliente.

Por que precisamos fornecer ao Gmail - ou qualquer outro site com contas de usuário - nosso nome de usuário e senha, se ele já estiver usando HTTPS? A resposta é a mesma da sua pergunta.

O HTTPS fornece, acima de tudo, uma conexão criptografada entre o servidor e o cliente.

A confiança inerente ao HTTPS é baseada nas principais autoridades de certificação pré-instaladas no software do navegador (isso é equivalente a dizer "Confio na autoridade de certificação (por exemplo, VeriSign / Microsoft / etc.) Para me dizer em quem devo confiar").

A menos que o servidor conceda a cada usuário um certificado , ele não poderá confiar no cliente sem outro método de autenticação.

O HTTPS é muito bom em evitar ataques de espionagem e "homem do meio". Como criptografa todo o tráfego para uma sessão.

Porém, como a maioria das pessoas está usando os certificados padrão fornecidos com o navegador e não tem idéia de como criar seu próprio certificado pessoal ou configurar o navegador para usá-lo.

Isso torna o HTTPS bastante inútil para autenticação do usuário, além de proteger uma caixa de diálogo de autenticação de escutas, etc.

HTTPS é sobre a proteção do canal, não provar quem é o chamador ou muitas outras coisas que você precisa considerar. Autenticação, autorização e criptografia da camada de transporte são apenas uma pequena parte do que você precisa considerar. Muitas das vulnerabilidades conhecidas relacionadas a aplicativos da web se aplicam muito às APIs REST. Você deve considerar a validação de entrada, quebra de sessão, mensagens de erro inadequadas, vulnerabilidades internas dos funcionários e assim por diante. É um grande assunto.

Robert

Você pode adotar a abordagem dos certificados SSL do cliente e separar a segurança da API. A grande desvantagem dessa abordagem é a sobrecarga da operação, que ficará cara quando mais e mais clientes consumirem sua API.

De qualquer forma, a autenticação básica HTTP é adequada para a grande maioria dos serviços consumidos publicamente.