protocolo

Termos comuns de segurança: HTTPS

Com certeza, ao navegar na internet, você já viu no começo da URL o protocolo HTTPS. Mas, você sabe para que serve e como funciona esse protocolo?

Primeiramente, antes de falarmos sobre HTTPS precisamos entender o que é o HTTP.

O que é HTTP?

HTTP é uma sigla para Hypertext Transfer Protocol (em português, Protocolo de Transferência de Hipertexto).

Trata-se do principal protocolo de comunicação utilizado para transferência de dados entre computadores utilizados na internet. Essa comunicação entre as máquinas envolvidas ocorre baseada em informações que trafegam como texto.

Para que esse sistema de comunicação em rede baseada em textos seja possível, o HTTP precisa trabalhar em conjunto com o TCP (Transmission Control Protocol), responsável pela transferência das informações; e com o protocolo IP (Internet Protocol), que cuida do encaminhamento dos dados. Juntos, os protocolos TCP e IP formam o modelo TCP/IP, modelo sob o qual o protocolo HTTP é executado.

HTTP - Fundamentos
Curso de HTTP - Fundamentos
CONHEÇA O CURSO

Como o HTTP funciona?

A comunicação realizada pelo HTTP segue o modelo cliente-servidor, baseando-se nos conceitos de request (pedido) e response (resposta). Um request corresponde a um pedido feito ao servidor. Uma mensagem de requisição do cliente é composta pelos seguintes campos de maneira geral:

Linha de pedido: formada pelo identificador do método HTTP (GET, POST, PUT, DELETE, etc.), URI do recurso (endereço para o qual será enviado o pedido) e versão do protocolo (geralmente, HTTP 1.1 e HTTP 2);

Cabeçalho: contém meta-informações sobre a requisição, como a identificação do cliente que está fazendo o pedido;

Corpo: contém os dados da requisição.

Já o response corresponde à resposta que é enviada pelo servidor. Geralmente, ele é composto dos seguintes componentes:

Linha de status: contém informações como a versão do protocolo utilizado no servidor, código numérico do status da resposta e o texto associado ao status;

Cabeçalho: é bem similar ao cabeçalho do pedido, ou seja, contém meta-informações e informações adicionais sobre o seu pedido e conteúdo de resposta;

Corpo: conteúdo de resposta para a requisição realizada (no caso de acesso a um site, seria o HTML para que o browser renderize a página, por exemplo).

De fato, essa comunicação baseada nesse modelo cliente/servidor é extremamente rápida e eficiente. Porém, existe um problema grande: toda essa comunicação que ocorre através do protocolo HTTP é baseada em texto puro, o que é completamente inseguro. E aqui entra o HTTPS.

HTTPS

O HTTPS é uma extensão do protocolo HTTP com a adição de uma camada de segurança na comunicação entre cliente/servidor, fazendo o uso do protocolo SSL (Secure Socket Layer).

Essa camada adicional permite que os dados sejam transmitidos por meio de uma conexão criptografada, além de garantir a verificação da autenticidade do servidor e do cliente por meio de certificados digitais.

Essas técnicas de criptografia servem para proteger os dados trafegados contra ataques de terceiros, minimizando bastante a possibilidade de que outras pessoas consigam ter acesso a informações que são trafegadas.

Por exemplo, quando você está em uma página servida através de HTTPS onde você precisa colocar seus dados (como uma página de login, por exemplo), esses dados são criptografados através de certificados digitais.

Nesse sentido, o fato de que o HTTPS em conjunto com o SSL pode prover aspectos de segurança adicionais faz com que até mesmo sua utilização seja praticamente obrigatória em alguns nichos (em e-commerces, por exemplo, é obrigatório o uso do certificado SSL para que seja possível autorizar compras com o cartão de crédito).

Afinal, o HTTPS realmente garante nossa segurança ao navegar pela web?

Definitivamente, protocolo HTTPS é considerado mais seguro porque ele faz uma criptografia forte dos dados trafegados ente clientes e servidores. Por isso, podemos concluir que o protocolo HTTPS de fato representa segurança. Porém, tal segurança se aplica somente ao âmbito da conexão e da comunicação entre clientes e servidores.

Uma conexão segura não significa necessariamente um site seguro: existem muitos outros tipos de brechas que podem ser exploradas em aplicações web que não envolvem necessariamente aspectos relacionados à conexão.

O que é OAuth 2?

OAuth 2 é um protocolo de autorização que permite que uma aplicação se autentique em outra. Para que isso aconteça, uma aplicação pede permissão de acesso para um usuário, sem que para isso ela tenha acesso a alguma senha dele. O usuário pode conceder ou não o acesso à aplicação. Depois da permissão ser aceita, caso o usuário precise alterar a senha de acesso, a permissão continuará válida para a aplicação e, caso necessário, a permissão dada à aplicação pode ser revogada a qualquer momento também.

Provavelmente você já clicou em algum botão escrito “Logar com sua conta do Google” ou “Logar com sua conta do Facebook” quando você está em alguma outra aplicação, para evitar de ter que fazer na mão algum cadastro. Neste caso, você está dando a autorização de uma aplicação terceira a usar os recursos da sua aplicação, neste caso o Google ou o Facebook. Essas aplicações têm acesso limitado às informações de usuários através do protocolo HTTP. OAuth 2 é utilizado nos mais diversos tipos de autenticação, como em telas de login e na autenticação de APIs (Application Programming Interface).

C# (C Sharp) - APIs REST com ASP.NET Web API
Curso de C# (C Sharp) - APIs REST com ASP.NET Web API
CONHEÇA O CURSO

Roles (papéis)

OAuth 2 foi construído em cima de 4 papéis, sendo:

  • Resource Owner – pessoa ou entidade que concede o acesso aos seus dados. Também chamado de dono do recurso.
  • Client – é a aplicação que interage com o Resource Owner, como por exemplo o browser, falando no caso de uma aplicação web.
  • Resource Server – a API que está exposta na internet e precisa de proteção dos dados. Para conseguir acesso ao seu conteúdo é necessário um token que é emitido pelo authorization server.
  • Authorization Server – responsável por autenticar o usuário e emitir os tokens de acesso. É ele que possui as informações do resource owner (o usuário), autentica e interage com o usuário após a identificação do client.

Como funciona?

Na imagem acima, podemos ver como geralmente funciona o fluxo de autorização.

  1. Solicitação de autorização
    Nessa primeira etapa o cliente (aplicação) solicita a autorização para acessar os recursos do servidor do usuário

  2. Concessão de autorização
    Se o usuário autorizar a solicitação, a aplicação recebe uma concessão de autorização.

  3. Concessão de autorização
    O cliente solicita um token de acesso ao servidor de autorização (API) através da autenticação da própria identidade e da concessão de autorização.

  4. Token de acesso
    Se a identidade da aplicação está autenticada e a concessão de autorização for válida, o servidor de autorização (API) emite um token de acesso para a aplicação. O cliente já vai ter um token de acesso para gerenciar e a autorização nessa etapa já está completa.

  5. Token de acesso
    Quando o cliente precisar solicitar um recurso ao servidor de recursos, basta apresentar o token de acesso.

  6. Recurso protegido
    O servidor de recursos fornece o recurso para o cliente, caso o token de acesso dele for válido.

    O servidor de autorização é responsável pelo SSO (Single Sign On), que centraliza as credenciais dos acessos dos usuários e faz a autenticação, gerencia as permissões dos usuários e emite os tokens de acesso.

O client (aplicação que roda na máquina do usuário) é definido através de dois tipos de aplicação:

  • Confidential – clients que são capazes de manter a confidencialidade das suas credenciais
  • Public – clients que são incapazes de manter a confidencialidade das suas credenciais

Continuando com os fluxos de autorização, existem 4 formas de se trabalhar com essa integração:

  • Implicit – é um fluxo de autorização simplificado, otimizado para clients web. Ao emitir um token de acesso, o authorization server não autentica o cliente. É muito utilizado em SPAs e aplicações MVC.
  • Authorization Code – é obtido usando um authorization server como intermediário entre o client e o usuário. O cliente redireciona o usuário para um servidor de autorização. Esse tipo de client é utilizado em aplicações de terceiros, ou seja, não confiáveis.
  • Resource Owner Password Credentials – utilizado quando o client solicita o usuário e senha diretamente, esse já utilizado em aplicações chamadas de confiáveis, como aplicações da própria empresa.
  • Client Credentials – pode ser utilizado quando a aplicação client é protegida, que são utilizados em integrações de sistemas.
Formação:
CONHEÇA A FORMAÇÃO

© 2004 - 2019 TreinaWeb Tecnologia LTDA - CNPJ: 06.156.637/0001-58 Av. Paulista, 1765, Conj 71 e 72 - Bela Vista - São Paulo - SP - 01311-200