APIs e Microsserviços

10 mai, 2018

ASP .NET Web API – Implementando a segurança via Tokens – Parte 01

Publicidade

Neste artigo vou mostrar como podemos implementar a segurança na Web API ASP .NET MVC 5.

Implementar a segurança em uma Web API é uma tarefa primordial para garantir a segurança do serviço da sua aplicação. Os dois tópicos básicos que envolvem a segurança, são:

  1. A autenticação: “Quem é você?”
  2. A autorização: “Quais recursos você pode acessar?”

Existem muitas tecnologias envolvidas nesse processo, e duas das mais conhecidas e já ultrapassadas, são:

  • Forms Authentication que grava cookies no navegador;
  • Windows Authentication que usa a conta corporativa do usuário para autenticação;

Na verdade, dentro do mundo web, existem diversas formas de validar as credenciais de um usuário. As principais, são:

Tipo de validação Descrição
Nenhuma Você não precisa conhecer a identidade do usuário ou não precisa proteger nada
Basic O chamador do serviço adiciona um cabeçalho de autorização HTTP contendo um nome de usuário e senha. Esses valores são essencialmente texto simples, usando apenas codificação base64 para ofuscação. Isso geralmente requer segurança de transporte SSL (Secure Sockets Layer) que expõe um endereço HTTPS para proteger o nome de usuário e a senha em texto sem formatação.
Digest Fornece um método mais sofisticado de colocar o nome de usuário e a senha no cabeçalho HTTP, que fornece criptografia para esses valores. O objetivo é evitar a necessidade de HTTPS.
Kerberos Usa um servidor de autenticação como um Windows Active Directory para fornecer a validação de credenciais.
Chave Pública e Certificados Depende de certificados fornecidos pelo chamador do serviço para identificar um usuário. Isso não é muito útil em um Web site público ou serviço, mas é muito apropriado para aplicações onde os usuários ou dispositivos são conhecidos.
Tokens (Bearer) Amplamente utilizado quando os emissores de token de terceiros estão envolvidos – por exemplo, OpenID e OAuth -, estes aliviam o seu serviço de ter que armazenar e verificar as credenciais de um usuário.
Uma vez autenticado, um serviço pode enviar um token para um usuário final através do qual o usuário pode acessar outros recursos. O token pode ser qualquer chave criptografada, que apenas o servidor/serviço entende, e quando busca o token a partir da solicitação feita pelo usuário final, ele valida o token e autoriza o usuário no sistema.

Nota: Lembrando que em uma Web API não temos sessão, e por isso o usuário deve se autenticar a cada requisição.

A autenticação (Bearer) que sua tokens é mais robusta que a autenticação Basic, pois nesta última, temos as credenciais do usuário nome/senha trafegados no header da requisição. As informações, embora codificadas no formato base64, podem ser facilmente decodificadas usando até o Fiddler ou Postman.

No caso da autenticação Bearer que usa tokens, temos o seguinte formato na requisição:

Autenticação Bearer

Content-Type: application/json
Authorization: Bearer TOKEN_USUARIO

Já a autenticação Basic usa esse formato:

Autenticação Basic

Content-Type: application/json
Authorization: Basic USUARIO_SENHA_BASE64

A Web API e o OAuth

Podemos usar o protocolo OAuth para realizar a autorização, sendo este uma especificação de como as aplicações devem se autorizar. Não importa se a aplicação é para a web, mobile ou desktop, desde que ela se comunique da forma padrão especificada e através de protocolo HTTP.

Você pode usar provedores de autorização diversos, fornecido por você de forma isolada ou, o mais comum, através de terceiros. Assim você não precisa se preocupar com o processo todo, apenas precisa saber se o usuário está autorizado ou não.

Desta forma, dados que precisam estar seguros ficam fora da aplicação e provavelmente nas mãos de quem sabe mantê-los seguros e possui a confiança do dono da informação. A aplicação só recebe o que for relevante para ela.

A Web API e o OWIN

Quando criamos uma Web API no Visual Studio por padrão, ela é compatível apenas com o IIS. Para usar outro host teremos que modificar os componentes da ASP .NET. Temos assim uma dependência da Web API que é o servidor IIS.

Para tornar uma Web API mais extensível e interagir com outros servidores e tecnologias tendo uma solução mais aberta, foi definida a especificação OWINOpen Web Interface for .Net para generalizar o acesso da aplicação a um host.

Essa especificação permite criar uma maneira padrão de comunicação entre a aplicação e o host, inclusive permite que a própria aplicação cuide disso, e a comunicação pode ser feita de forma mais flexível, leve e personalizada para cada situação.

O OWIN é justamente a especificação de como essa comunicação funciona. Algumas implementações desta especificação, são: Katana, que permite o self-host da aplicação e o Helios, que permite o uso com o IIS.

Nota: O Katana é um projeto de código aberto da Microsoft Open Technologies. É um conjunto de componentes para criar e hospedar aplicativos da Web baseados em OWIN que seguem a especificação OWIN.

Como transformar uma Web API em uma aplicação OWIN

Assim o objetivo do OWIN é que sua aplicação não fique vinculado a um Sistema Operacional nem a um servidor. Além disso, aplicações OWIN tem um melhor desempenho. Com isso em mente podemos transformar nossa Web API em uma aplicação OWIN aplicando alguns pacotes.

Após criar sua aplicação Web API usando o template Empty, acesse o menu Tools > Nugetr Package Manager > Package Manager Console para abrir o console do Nuget, e a seguir instale os pacotes abaixo:

  • Install-Package Microsoft.AspNet.WebApi.Owin: instala o protocolo OWIN
  • Install-Package Microsoft.Owin.Host.SystemWeb: a implementação Microsoft do OWIN (Katana)

Para instalar o pacote para o OAuth e habilitar o CORS, instale os pacotes a seguir:

  • Install-Package Microsoft.Owin.Security.OAuth
  • Install-Package Microsoft.Owin.Cors

Dessa forma, para implementar a autenticação via Token(Bearer) e OWIN, todos os pacotes acima serão necessários.

Apenas para constar, a implementação via Token(Bearer) possui os seguintes vantagens:

  • Baixo acoplamento
  • Sem cookies
  • Prazo de validade definido
  • Independe da validação das informações

Na próxima parte do artigo veremos como criar uma Web API e implementar a proteção da Web APi usando a implementação via Token.