Autenticação e Autorização com OAuth2.0 e OpenID Connect
Hoje, mais do que nunca, a cibersegurança tem de ser vista como algo essencial e não um simples “add-on”, por isso, é necessário garantir que a informação certa chega à pessoa certa. Mais importante do que isso, é necessário garantir que a informação “errada” permanece segura e indisponível a terceiros. No entanto, com o crescimento exponencial da informação que dispomos online, torna-se mais complicado manter esses dados secretos. Aqui entra o OAuth2.0, um protocolo que restringe o acesso a dados, de forma a que, apenas os dados necessários sejam disponibilizados a um serviço de terceiros, ao invés de todas as nossas informações. Ou seja, é necessária uma autorização por parte do utilizador no acesso aos dados. Da mesma maneira, é possível descentralizar a autenticação de um serviço, através do protocolo OpenID Connect, que atua como uma espécie de extensão ao OAuth2.0. Ou seja, um utilizador pode facilitar o seu registo ou login num novo serviço, utilizando dados externos sem nunca introduzir um dado ou conceder uma password. Assim, estes dois protocolos colaboram para uma maior proteção de dados pessoais, facilitando qualquer processo de acesso a dados externos a um serviço.
Autenticação e Autorização
Para compreender onde e como atua o OAuth2.0 é necessário perceber em que consistem os conceitos Autenticação e Autorização. Por Autenticação entende-se a verificação do utilizador, ou seja, quem é o utilizador, enquanto que Autorização é o processo de verificação dos dados a que um serviço / utilizador tem acesso. Isto é, a autenticação é realizada, por exemplo, num processo de login, enquanto que a Autorização acontece quando há uma tentativa de acesso a dados pessoais e o utilizador dá a sua permissão. Grande parte das vezes, estes processos trabalham em sintonia, uma vez que para aceder a dados de terceiros e, consecutivamente, poder ser realizada uma autorização de acesso, é necessária uma autenticação prévia, para saber a que utilizador correspondem os dados a que se pretende aceder.
O Fluxo do OAuth2.0
O fluxo comum do OAuth2.0 segue a seguinte ordem:
1) Numa aplicação é pedido ao utilizador um serviço “chave” para extrair os dados necessários ou os dados requeridos para a autenticação. Por exemplo, é possível usar o Facebook para fazer um registo / login numa aplicação (acedendo aos dados de e-mail, nome de utilizador e imagem de perfil) ou, de outra forma, podemos pedir acesso à lista de amigos do Facebook para encontrar “amigos” em comum numa outra aplicação. Em ambos estes casos, há uma necessidade de acesso a dados externos, ainda que com objetivos diferentes.
2) Depois de selecionado o serviço de onde se pretende extrair os dados, o utilizador é redirecionado para uma página onde, caso não tenha sessão iniciada, terá de efetuar o login nesse mesmo serviço, para confirmar e reconhecer a que utilizador se pretende extrair os dados. Dessa forma, a autenticação é sempre realizada no serviço “chave”, de forma segura, e nunca no serviço externo, pelo que os dados se mantêm seguros.
3) Efetuado o login, o utilizador depara-se com uma janela onde são listados os dados a que se pretende aceder. A esta janela dá-se o nome de “janela de consentimento” e é onde o utilizador permite ou não o acesso às informações listadas.
4) Por último, caso o acesso aos dados selecionados seja consentido, o utilizador é redirecionado, de novo, para a aplicação, onde já tem acesso aos dados que necessitava.
Assim se faz uma autenticação segura e rápida, onde a aplicação não tem acesso a qualquer dado sensível do utilizador (como passwords), e consegue aceder, unicamente, aos dados requeridos para autenticar um utilizador. É exatamente este conforto e facilidade que oferece o OAuth2.0. Parece simples e seguro, não é?
Por trás do Fluxo do OAuth2.0
Na verdade, é. No entanto, é importante saber o que se passa por trás de todo este fluxo para perceber e garantir o nível de segurança a que os utilizadores têm direito. Utilizando os passos do fluxo mencionado acima, será explicado o que acontece na ligação entre utilizador e servidores, e como é que todo este processo é garantido.
1) Num primeiro momento, o utilizador faz um pedido a uma aplicação para conectar a sua conta a um serviço externo, por exemplo, o Facebook. Neste caso, o serviço externo será o Servidor de Autorização e o Servidor de Recursos, visto que é o serviço onde se pretende extrair dados e é necessário permitir o acesso. Já a aplicação que irá obter esses dados será a Aplicação Cliente, visto que irá buscar os dados em nome do Utilizador. No entanto, ao realizar este pedido são enviados parâmetros essenciais juntamente com ele:
a) O ClientID, que representa um ID único e pessoal da Aplicação Cliente;
b) O URL de Redirecionamento, que corresponde ao link para o qual o Utilizador será redirecionado no fim do consentimento de acesso aos dados;
c) O Response Type, que representa o tipo de resposta do Servidor de Recursos, que, neste caso, será do tipo Code (algo explicado mais à frente);
d) E, por último, o Scope, que representa o conjunto de dados a que a Aplicação Cliente pretende aceder;
2) Depois de processado e validado o pedido com os respetivos parâmetros, a Aplicação Cliente redireciona o Utilizador para a página de autenticação do OAuth2.0 do Servidor de Recursos, onde o Utilizador realiza a autenticação para dar a conhecer a sua identidade. Como se pode verificar, o Utilizador mantém a segurança dos seus dados e das suas credenciais, visto que a comunicação está a ser feita, unicamente, entre Utilizador e Servidor de Recursos
3) Efetuado o login, o Servidor de Recursos apresenta a janela de Consentimento, onde o utilizador consente em dar acesso aos dados solicitados pela Aplicação Cliente.
4) Depois de processado o consentimento e o acesso aos dados, o Servidor de Recursos redireciona o Utilizador, novamente, para a Aplicação Cliente, através do URL de redirecionamento passado, e envia como parâmetro um Código de Autorização. Este código é relativo ao Response Type mencionado anteriormente, onde o valor passado foi “Code”.
Seria de esperar que, dado este processo, a Aplicação Cliente já tivesse acesso aos dados através deste Código de Autorização. Mas não, ainda há mais um passo neste fluxo!
5) Depois de recebido o Código de Autorização, a Aplicação Cliente usa-o para aceder aos dados estabelecidos, trocando o Código de Autorização, o ClientID e um Client Secret (código aleatório gerado, unicamente, na comunicação entre servidores no início do processo) por um Access Token do Servidor de Recursos. É a troca destes códigos e o acesso ao Access Token que garante, finalmente, o acesso aos dados. No entanto, é importante salientar que, esta última troca de dados, é feita, exclusivamente, entre o servidor da Aplicação Cliente e o Servidor de Recursos, sem nunca passar pelo Utilizador. É este aspeto oculto que garante a segurança dos dados, visto que o fator que assegura o acesso aos dados nunca passa pelo Utilizador. É, também, por esse motivo, que o Access Token só pode ser acedido depois da troca dos códigos certos, para garantir a máxima proteção dos dados em circulação e nunca permitir o acesso destes códigos a browsers, visto que estes não são controlados.
OpenID Connect
Todo o fluxo descrito anteriormente explica como é possível aceder a dados do utilizador através de aplicações de terceiros de maneira segura e eficaz. Mas onde entra o OpenID Connect? O OpenID Connect atua como uma extensão do OAuth2.0, no sentido em que não lhe é exterior, mas complementa o serviço. Enquanto que o OAuth2.0 “trabalha” com Autorizações, o OpenID Connect encarrega-se da Autenticação, no entanto, trabalham sempre em sintonia.
No uso do OpenID Connect, todo o fluxo de Autenticação ocorre da mesma maneira que o fluxo de Autorização do OAuth2.0, no entanto, no parâmetro de Scope, é solicitado um Scope relativo ao OpenID Connect que, ao invés de retornar, unicamente, uma chave como Access Token, retribui, também, alguma informação sobre o Utilizador.
Este processo permite que um único registo de login seja utilizado em inúmeros cenários de login de terceiros como, por exemplo, dar a oportunidade a um utilizador de iniciar sessão numa aplicação através da sua conta Facebook. Outro exemplo relevante é, por exemplo, o uso de um cartão bancário num multibanco, onde, para além de permite acesso à conta bancária (Autorização), o cartão oferece alguma informação sobre o Utilizador do cartão (Autenticação).
Conclusão
Numa época onde os dados dos utilizadores nunca foram tão valiosos, a privacidade de dados é o foco na matéria da cibersegurança. O protocolo do OAuth2.0 garante, eficazmente, a segurança desses dados e dá a conhecer aos utilizadores os dados que estão a ser disponibilizados para o exterior de um ambiente. O seu aspeto de valor distintivo e único é o facto de isolar os dados dos utilizadores num sistema independente de autenticação e permitir trocas seguras com o exterior, possibilitando, ainda, autenticações descentralizadas, seguras e únicas. No entanto, um dos fatores mais importantes destes processos, onde se inclui o protocolo OpenID Connect, é a facilidade destes processos e o que oferecem em User Experience. Nunca foi tão fácil, rápido e seguro fazer a autenticação numa aplicação nova. O OAuth2.0 é, definitivamente, o futuro, pois garante a lei do menor esforço com a maior segurança.
Bibliografia
Authentication and OAuth — Codecademy
An Illustrated Guide to OAuth and OpenID Connect — David Neal
