Entre a sua publicação, registrada em outubro de 2012, e os dias atuais, o OAuth 2 deixou um legado inegável. Tanto que hoje já está disponível o OAuth 2.1, que pode ser considerado um compilado das boas práticas de sua versão anterior. No entanto, muitos ainda se questionam sobre como migrar para esse novo padrão aberto de delegação de autorização e se usuários do OAuth 2 sofrerão algum impacto com a implementação da mencionada variante.
Neste artigo vamos entender melhor os ganhos que o OAuth 2.1 trouxe para a realidade do desenvolvimento, quais são os benefícios em adotá-lo e o que o futuro reserva para novas versões de open authorization.
O que é OAuth 2?
A definição simples traz como exemplo uma prática recorrente entre usuários de aplicações online – quando alguém utiliza a sua conta no Google para fazer login em outra plataforma, está utilizando o OAuth2, um protocolo de autorização que permite a autenticação de uma aplicação por meio de outra. Em outras palavras, graças a esse protocolo é possível aceder a múltiplas contas sem digitar uma senha. Para usufruir dessa praticidade, basta que o usuário conceda o acesso entre aplicações, a qual também pode ser rescindida a qualquer momento.
O fluxo da autorização ocorre em 6 passos. São eles:
- Solicitação de autorização para acessar os recursos do servidor do usuário
- Recebimento da autorização por parte do usuário
- Solicitação de um token de acesso ao servidor de autorização, realizada com a autenticação de identidade e com a concessão do passo anterior
- Emissão de token para acesso da aplicação
- Apresentação do token de acesso para solicitação de recursos ao servidor
- Entrega dos recursos mediante a existência de um token válido
A centralização das credenciais dos acessos e a autenticação é feita pelo servidor de autorização, responsável pelo SSO (em inglês, Single Sign On), pelo gerenciamento das permissões dos usuários e pela emissão dos tokens de acesso.
O que mudou com o OAuth 2.1?
Ainda que haja espaço para mapear entregas superiores feitas pela versão 2.1 do OAuth, existem mudanças já reconhecidas por especialistas. Mas afinal, quais são elas?
- Não é possível utilizar token de portador na string de consulta de URIs (em inglês, Uniform Resource Identifier) com o token do portador.
- Tokens de atualização ficam limitados ao remetente ou a uma única utilização.
- Adicionando os parâmetros PKCE (em inglês, Proof Key for Code Exchange), a concessão do código de autorização é estendida.
- A comparação dos URIs deve ser feita através da correspondência exata da sequência conforme tido nas práticas de segurança recomendadas para OAuth 2.
- Ocorre a omissão da concessão das credenciais de senha do proprietário do recurso, igualmente pautada nas práticas de segurança para o OAuth 2.
E o que se manteve?
O surgimento do OAuth 2.1 foi baseado nas RFCs (em inglês, Requests For Comments) do 2.0, ou seja, comportamentos que não foram alterados ou omitidos da versão anterior permanecem intactos. Um exemplo é a concessão de credenciais do cliente, que continua disponível para viabilizar a comunicação entre servidores.
Contudo, o que deve ser herdado do OAuth 2 ainda é incerto, pois a variante mais recente segue em andamento não somente para consolidar, mas também para simplificar os seus recursos apontados como os mais populares.
Dicas de preparação
Mesmo que ainda não tenha sido lançado oficialmente, o OAuth 2.1 requer certa lapidação de práticas de segurança. Aplicativos precisam estar prontos para absorver os benefícios de um draft que não está longe de ser compartilhado com o mercado. Vejamos quais são as recomendações.
Primeiramente, sugere-se evitar tanto a concessão implícita quanto a concessão de credenciais de senhas. É igualmente importante que o servidor OAuth 2 atualmente empregado seja capaz de utilizar PKCE em todos os momentos que a concessão do código de autorização for utilizado. Correspondências curinga ou substring não podem ser comparadas aos URIs de redirecionamento. Os tokens de atualização devem ser limitados, de preferência a um único uso. Por fim, os tokens do portador jamais devem estar presentes na string de consulta.
O futuro do OAuth
Os mesmos especialistas que identificaram os pontos superiores do OAuth 2.1 em relação ao OAuth 2 sentem dificuldade em prever quais são as surpresas reservadas para esse protocolo padrão de autorização. O que se sabe é que o objetivo maior da sua versão mais recente é consolidar as boas práticas de segurança, evitando promover grandes alterações.
Por outro lado, existem profissionais focados em entregar uma geração superior do OAuth 2 e que estão desenhando, do zero, um protocolo de negociação e autorização de concessão. Embora os idealizadores de tal trabalho não visem compatibilidade com o original OAuth 2, o que eles querem introduzir é um processo de migração simplificado que garanta aderência à inovação ainda em fase de discovery.
Créditos arte: Image by Freepik
