Conhecendo OAuth2

  • Rafael Miceli
  • 14 Abr 2016

Muitas aplicações que fazemos em algum ponto vai necessitar algum tipo de autorização para que um usuário consiga acessar o conteúdo de alguma página, ou de alguma API.

OAuth2 é um excelente protocolo e atualmente uma das maneiras mais versáteis para realizar esta tarefa.

Quando usar o OAuth2

Ok, preciso usar Oauth em minha aplicação?

Depende.

Sua aplicação vai dar suporte a varias plataformas para acesso? Por exemplo: pretende criar uma aplicação web e um aplicativo mobile para acessar uma API? Então OAuth2 é uma excelente pedida.

Vai criar uma aplicação mais simples client-server intranet, ou até uma aplicação web bastante simples? Então é bom avaliar outras opções e se Oauth é sua pedida, uma vez que tem uma curva de aprendizagem para seu uso e a implementação do mesmo não é TÃO trivial.

Porque usar OAuth2?

No passado, para aplicações tradicionais na Web, poderíamos usar SAML ou WS* para autorização, mas para o cenário moderno a coisa muda de figura.

Para aplicativos de smartphones ou tablets OAuth2 é a melhor maneira de se trabalhar, uma vez que smartphones ou tabletes não possuem bibliotecas de XML complexas para o processamento dos antigos protocolos.

Além disso, por OAuth2 trabalhar com JWT (Json Web Tokens, melhor explicado em um post futuro), isso torna a troca de mensagens muito mais leve e muito mais fácil de decodificar. Afinal praticamente qualquer plataforma trabalha com Javascript, além de ser a linguagem de front favorita na web.

Funcionamento

A ideia é a seguinte:

Imagina que você possui um sistema web para gerenciar os alunos de uma escola (Tem um bem simples assim em meu Github). Esse sistema que gerencia nossos alunos chamamos de Resource Server.

Em uma autorização tradicional, o mesmo sistema de Escola seria responsável por autenticar e autorizar os usuários, provavelmente criando um cookie para o mesmo.

Usando Oauth vamos ter uma nova aplicação, que vamos chamar de Authorization Server. Nosso Authorization Server é o responsável por gerar a chave de permissão para o nosso Resource Server. E nós temos ainda mais dois players no OAuth que são o Client e o Resource Owner.

O Client sempre foi nos dito que é quem está usando nossa aplicação, ou o cliente da aplicação, mas no contexto do OAuth, o Client é o software que acessa nosso Resource Server.

Para ficar fácil, imagina um aplicativo de celular, ele vai precisar acessar a API de nossa aplicação Escola (Resource Server) para consumir os dados e exibir ao nosso usuário que é o Resource Owner

Mas e se meu Resource Server também tem o papel de Client, por exemplo: Tenho uma aplicação MVC e WebApi no mesmo project? Sem problemas, só veremos mais tarde qual melhor flow usar para sua aplicação.

Mas para facilitar um pouco o que falei acima, uma imagem sempre facilita:

roles

No próximo artigo vamos ver alguns flows que o OAuth possui e qual usar em determinadas situações.

comentarios com Disqus Disqus