A autenticação e a autorização desempenham um papel essencial num mundo digital onde a segurança de dados e a privacidade são prioridades. Imagine a situação em que uma aplicação de terceiros precisa de aceder a um ou mais dos seus serviços online, mas você/a sua empresa não deseja partilhar as credenciais de login. Como é possível garantir a proteção dos dados enquanto permite que essa aplicação aceda apenas às informações necessárias? É aí que entra o OAuth 2.0.


O OAuth 2.0 é um protocolo de autorização utilizado por aplicações modernas para proteger dados e recursos. Oferece um modelo seguro e confiável para permitir que os utilizadores concedam, a aplicações de terceiros, acesso aos seus recursos protegidos – como fotos, e-mails ou contactos – sem partilharem as suas credenciais de login.

 

Se você é um Engenheiro de Software em busca de um protocolo confiável e seguro para autorização, ou um utilizador preocupado com a privacidade e segurança dos seus dados, este artigo fornecerá uma visão abrangente do OAuth 2.0 e de como podemos aplicá-lo na arquitetura das nossas soluções.

  

Autenticação vs. Autorização

A autenticação trata-se do processo de verificação da identidade de um utilizador ou entidade que está a tentar aceder a um sistema ou recurso. É a etapa inicial em que as credenciais são fornecidas – como login e senha – para comprovar a sua identidade. A autenticação garante que apenas utilizadores legítimos acedam aos sistemas e dados, prevenindo o acesso não autorizado por indivíduos mal-intencionados.

 

Por outro lado, a autorização está relacionada com os privilégios e permissões concedidos a um utilizador autenticado. Uma vez autenticado, o utilizador passa pelo processo de autorização, que determina quais as ações e recursos que está autorizado a aceder. Isso envolve a definição de níveis de acesso, restrições e direitos de um utilizador específico. A autorização garante que os utilizadores tenham acesso somente aos recursos apropriados e restringe o acesso a informações confidenciais ou funcionalidades que não sejam relevantes para as suas funções.

 

O que é OAuth 2.0

O OAuth 2.0 é um protocolo de autorização que permite que recursos protegidos possam ser acedidos por terceiros sem que haja partilha das credenciais de login. O protocolo envolve diferentes atores e fluxos de autorização.

 

Foi desenvolvido pela IETF (Internet Engineering Task Force), uma organização responsável pelo desenvolvimento de padrões de Internet. O grupo de trabalho responsável pela criação do OAuth 2.0 (chamado de “OAuth Working Group”) foi liderado por Aaron Parecki, Eran Hammer, Dick Hardt e outros especialistas em segurança e autenticação.

 

Este protocolo foi baseado no seu antecessor, o OAuth 1.0. Esse, por sua vez, tinha as suas limitações e, com base nas experiências anteriores e nos requisitos crescentes da indústria, foi criada uma nova versão mais simples e flexível, resultando no OAuth 2.0.

 

Fluxos de autorização do OAuth 2.0

Vários fluxos ou grant types são definidos no protocolo, podendo ser utilizados para realizar a autenticação e a autorização entre um cliente, um authorization server e um servidor de recursos. Cada fluxo é projetado para atender a diferentes cenários de uso, dependendo das necessidades de segurança e dos requisitos da aplicação.

 

Os fluxos mais comuns do OAuth 2.0 são: “Authorization Code Flow”, “Implicit Flow”, “Resource Owner Password Credentials Flow”, “Client Credentials Flow” e “Refresh Token Flow”.

  • Authorization Code Flow: Fluxo mais comum em aplicações web. Consiste na troca de um código de autorização por um token de acesso. O utilizador é redirecionado para o provedor de autenticação, que faz login e concede permissão para a aplicação aceder aos seus recursos. De seguida, a aplicação troca o código de autorização por um token de acesso que pode ser usado para fazer chamadas em nome do utilizador;
  • Implicit Flow: Semelhante ao Authorization Code Flow, mas mais apropriado para Aplicações de Página Única (SPA), onde o client não pode manter o token com segurança. Nesse fluxo, o token de acesso é retornado diretamente no redirecionamento inicial após a autenticação bem-sucedida do utilizador;
  • Resource Owner Password Credentials Flow: Aqui as credenciais do utilizadores são enviadas diretamente ao authentication server para obter um token de acesso. Esse fluxo é mais adequado para aplicações confiáveis, como aplicações de linha de comando ou dispositivos que pertencem ao utilizador;
  • Client Credentials Flow: A aplicação client autentica-se diretamente com o servidor de recursos, utilizando as suas próprias credenciais, o client ID e o client secret. Não há envolvimento do utilizador nesse fluxo, pois a aplicação está a obter acesso em seu próprio nome, não em nome de um utilizador específico. Esse fluxo é comumente usado em integrações de servidor a servidor;
  • Device Authorization Flow: Esse fluxo é adequado para dispositivos com recursos limitados, como TV inteligentes ou dispositivos IoT. Nesse fluxo, o dispositivo exibe um código para o utilizador se autenticar noutro dispositivo e fornecer a autorização necessária. O dispositivo pode então trocar o código por um token de acesso.

 

OAuth 2.0 junto de microsserviços

Numa arquitetura de microsserviços, o fluxo mais utilizado é o Client Credentials Flow, pois é usado quando uma aplicação client deseja autenticar-se diretamente com o authorization server, sem a necessidade de envolver um utilizador.

 

Aqui está uma explicação detalhada do fluxo de Client Credentials:

  1. Registo do cliente: Antes de o fluxo se iniciar realmente, a aplicação client precisa de ser registada no authorization server, para que possa existir um client ID e um client secret associados, que serão utilizados para a autenticação junto do authorization server;
  2. Solicitação de token de acesso: A aplicação client solicita ao authorization server o token de acesso – para isso é fornecido o client ID, o client secret e o objetivo de acesso desejado. A solicitação também inclui o grant type definido como “client_credentials” para indicar o uso do fluxo de Client Credentials;
  3. Autenticação do cliente: O authorization server verifica se o client ID e o client secret correspondem aos registos da aplicação client;
  4. Emissão do token de acesso: Se as credenciais da aplicação client forem autenticadas com sucesso, o authorization server gera um token de acesso, que é a prova de que a aplicação client foi autenticada e tem permissão para aceder aos recursos protegidos solicitados;
  5. Acesso aos recursos protegidos: A aplicação client envia o token de acesso em cada solicitação, geralmente no cabeçalho Authorization do formato “Bearer <token>”. O servidor de recursos verifica a validade e a autenticidade do token antes de conceder acesso aos recursos.
  6. Renovação do token de acesso: O token de acesso emitido no fluxo de Client Credentials tem um tempo de vida limitado. Para obter um novo token de acesso após a sua expiração, o cliente deve repetir o fluxo, enviando novamente as suas credenciais e solicitando um novo token de acesso.

 

Conclusão

Neste artigo explorámos o poderoso protocolo de autorização OAuth 2.0 e a sua importância na autenticação segura de aplicações e serviços. Compreendemos a diferença entre autenticação e autorização, apresentámos os diferentes fluxos do OAuth 2.0 e detalhámos o fluxo Client Credentials Flow. Ao entender esses conceitos, os developers podem integrar sistemas e plataformas com segurança, facilitando a colaboração entre aplicações.

 

É essencial seguir as melhores práticas de implementação e considerar potenciais ameaças, mas com o conhecimento do OAuth 2.0 estamos preparados para criar soluções tecnológicas mais seguras e integradas, impulsionando o desenvolvimento de software num ambiente confiável.
Partilha este artigo