O futuro da autorização: por que o OAuth 2.0 é apenas o começo

A autorização é um componente crítico da segurança do aplicativo, permitindo apenas que usuários autenticados e autorizados acessem recursos protegidos. OAuth 2.0 tornou-se o protocolo padrão do setor para autorização, fornecendo uma estrutura para controle de acesso delegado.

Publicado pela primeira vez em 2012, o OAuth 2.0 permite que aplicativos acessem recursos hospedados por um servidor de recursos em nome do proprietário do recurso, por meio da emissão de tokens de acesso. Ele permite que os usuários concedam a aplicativos de terceiros acesso aos seus dados em outro serviço, sem expor suas credenciais.

OAuth foi amplamente adotado em toda a web, possibilitando autorização para muitas plataformas importantes, incluindo Facebook, Google, Twitter e Microsoft. No entanto, à medida que o uso do OAuth cresceu exponencialmente, também foram descobertas vulnerabilidades e pontos fracos. Isso permitiu que invasores roubassem tokens de acesso e se passassem por usuários válidos.

Neste artigo, forneceremos uma visão geral de como o OAuth 2.0 funciona, casos de uso comuns, práticas recomendadas e vulnerabilidades. Também olharemos além do OAuth para protocolos de autorização e autenticação mais avançados que visam aumentar a segurança – OpenID Connect, TLS mútuo e WebAuthn. Ao final, você terá um conhecimento sólido do OAuth 2.0 e de como utilizá-lo com segurança. Além disso, você obterá insights sobre novos padrões e técnicas que vão além do OAuth para proteger ainda mais o controle de acesso para aplicativos modernos.

Como funciona o OAuth 2.0

OAuth 2.0 é um padrão aberto para delegação de acesso que fornece autorização segura para aplicativos acessarem recursos do servidor em nome de um usuário. Ele permite que os usuários concedam acesso limitado aos seus recursos sem expor suas credenciais.

OAuth 2.0 define quatro fluxos de autorização principais:

Fluxo do código de autorização

O fluxo do código de autorização é mais adequado para clientes confidenciais, como aplicativos da web. Envolve um código de autorização intermediário para troca por um token de acesso:

A aplicação cliente redireciona o usuário ao servidor de autorização para efetuar login e aprovar o acesso.
O servidor de autorização autentica o usuário e o redireciona de volta com um código de autorização.
O cliente troca o código de autorização por um token de acesso.
O cliente pode usar o token de acesso para fazer chamadas de API para acessar recursos.

Esse fluxo proporciona maior segurança porque o token de acesso nunca é transmitido diretamente pelo navegador do usuário.

Fluxo ImplícitoO fluxo implícito é otimizado para clientes baseados em agente de usuário, como aplicativos Web de página única. O token de acesso é retornado diretamente sem código de autorização:

A aplicação cliente redireciona o usuário ao servidor de autorização para efetuar login e aprovar o acesso.
O servidor de autorização autentica o usuário e redireciona de volta com um token de acesso no fragmento de URL.
O cliente pode usar o token de acesso para fazer chamadas de API para acessar recursos.

Esse fluxo simplificado elimina a necessidade de viagens extras ao servidor de autorização, mas é menos seguro porque o token de acesso é exposto no histórico do navegador.

Comparação de fluxos

O fluxo do código de autorização é mais seguro, mas envolve mais viagens de ida e volta. O fluxo implícito é mais simples e otimizado para clientes agente-usuário em detrimento da segurança.

No geral, o OAuth 2.0 fornece uma estrutura segura de autorização delegada para que aplicativos clientes acessem recursos do servidor de maneira padronizada. No entanto, vulnerabilidades ainda existem se não forem implementadas adequadamente.

Prós e Contras do OAuth 2.0

Prós:

Autorização delegada sem compartilhar credenciais de usuário
Fluxos de autorização flexíveis para vários tipos de clientes
Ampla adoção nas principais plataformas e provedores

Contras:

A complexidade leva a erros comuns de implementação
Depende de HTTPS e sigilo de token para segurança
Os tokens de acesso podem vazar se não forem devidamente protegidos
Contexto de usuário integrado limitado além dos escopos

OAuth 2.0 resolve o principal problema da autorização segura, mas apresenta pontos fracos que protocolos mais avançados tentam resolver.

Casos de uso do OAuth 2.0

OAuth 2.0 é comumente usado para permitir fluxos de autorização em uma ampla variedade de aplicativos e serviços na Internet. Alguns dos casos de uso e exemplos mais comuns incluem:

Login de mídia social - Serviços como Facebook, Twitter, Google e GitHub aproveitam o OAuth 2.0 para permitir que os usuários “façam login com” suas credenciais de plataforma. Isso permite que os usuários renunciem à criação de novas contas e, em vez disso, autorizem esses sites a se conectarem aos seus perfis sociais existentes.
Autorização de aplicativos - Aplicativos móveis e de desktop geralmente integram o OAuth para autorizar o acesso a APIs REST. Por exemplo, um aplicativo pode usar o OAuth para obter acesso às fotos de um usuário em um serviço de armazenamento em nuvem, aos contatos em um serviço de catálogo de endereços ou a outros dados de um provedor de API.- Segurança e logon único - OAuth permite autenticação centralizada por meio de um único provedor de identidade, em vez de gerenciar credenciais para cada aplicativo individualmente. Essa abordagem de logon único (SSO) é popular em ambientes corporativos para melhorar a segurança e a conveniência.
Proteção de conta de usuário - Para usuários preocupados com a segurança, o OAuth permite autorizar o acesso a aplicativos sem nunca compartilhar suas credenciais primárias. Isso protege a conta do usuário caso um aplicativo seja comprometido ou malicioso.
Integração de serviços - OAuth permite integração perfeita entre diferentes plataformas por meio de seus fluxos de autorização e tokens de acesso. Os serviços podem se conectar diretamente uns aos outros por meio de APIs em nome dos usuários, evitando atritos e complicações na condução de etapas de autenticação redundantes.

Em resumo, o OAuth 2.0 fornece uma estrutura padronizada para conceder acesso limitado aos dados e capacidades do usuário sem expor credenciais. Seus fluxos flexíveis e formato de token o tornam um protocolo amplamente aplicável para autorização em integrações web, móveis, desktop, IoT e baseadas em API. OAuth 2.0 é a base de grande parte da interoperabilidade perfeita entre aplicativos e serviços na web moderna.

Práticas recomendadas do OAuth 2.0

Para aproveitar totalmente os benefícios de segurança do OAuth 2.0, é importante seguir as práticas recomendadas em relação ao registro, chaves, tokens e tokens de atualização.

Registro e manuseio de chaves

Use HTTPS para os pontos de extremidade de autorização e token. Isso protege contra ataques man-in-the-middle.
Gere chaves criptograficamente fortes com entropia suficiente. Os tamanhos de chave recomendados são 2.048 bits para RSA e 256 bits para EC.
Nunca codifique segredos de clientes em aplicativos nem compartilhe segredos com partes não confiáveis. Armazene segredos com segurança no lado do servidor.
Defina prazos de validade curtos para códigos de autorização, em torno de 10 minutos. Isso reduz a janela de interceptação.
Revogue imediatamente os segredos do cliente expostos e gere novas chaves.

Uso de token

Mantenha os tokens de acesso de curta duração, cerca de 1 hora. Os tokens de atualização podem ter validade mais longa, cerca de 2 semanas.
Envie tokens de acesso somente por HTTPS e apenas para back-ends confiáveis. Nunca inclua tokens em URLs, logs ou código front-end.
Sempre valide o público do token para corresponder ao público esperado para sua API.
Verifique se o emissor corresponde ao domínio do seu servidor de autorização.
Verifique o algoritmo de assinatura de token e a chave em relação às chaves confiáveis conhecidas.

Atualizar tokens- Emita tokens de atualização apenas para aplicativos e dispositivos próprios e confiáveis. Evite fornecer tokens de atualização para clientes de terceiros.

Vincule tokens de atualização a uma única combinação específica de ID de cliente e identidade de usuário.
Revogar tokens de atualização quando o usuário fizer logout ou as permissões forem alteradas. Emita novos tokens na reautenticação.
Tokens de atualização seguros equivalentes à autorização de longo prazo. Transmita apenas por HTTPS e restrinja o acesso por meio de criptografia.

Seguir essas práticas recomendadas garantirá que o OAuth 2.0 forneça segurança robusta para autorização de API.

Vulnerabilidades do OAuth 2.0

Embora o OAuth 2.0 seja uma melhoria em relação aos protocolos de autenticação anteriores, ele ainda apresenta vulnerabilidades que os invasores podem explorar se não for implementado e protegido adequadamente. Alguns ataques OAuth comuns incluem:

Sequestro de token - Um invasor rouba um token de acesso e o utiliza para obter acesso não autorizado a recursos. Isso pode acontecer se os tokens não forem devidamente protegidos ou transmitidos por canais inseguros.
Interceptação do código de autorização - O código de autorização usado para trocar por um token de acesso pode ser interceptado por um invasor durante o processo de autorização, permitindo-lhe obter um token de acesso válido.
Personificação de cliente - Um invasor finge ser um cliente válido para enganar o servidor de autorização e fazê-lo emitir um token de acesso. A autenticação fraca do cliente torna isso possível.
Personificação de usuário - O invasor rouba ou adivinha as credenciais de um usuário e as utiliza para autenticar-se como usuário e obter acesso aos seus dados.
Fluxos OAuth quebrados - A implementação incorreta de fluxos e validação OAuth pode deixar endpoints abertos à exploração. Os invasores podem abusar de falhas na validação de redirect_uri, parâmetros de estado e emissão de código/token para comprometer contas.
Falsificação de solicitação entre sites (CSRF) - Os invasores podem forçar usuários autenticados a fazer solicitações inadvertidamente em seu nome, explorando a dependência do OAuth no redirecionamento do navegador para fluxos.
Redirecionadores abertos - Permitir redirecionamentos abertos após o login do OAuth pode permitir que invasores redirecionem usuários para sites de phishing e roubem credenciais ou tokens.

Para evitar o abuso do OAuth, a implementação adequada é crucial:

Use parâmetros de estado e nonce para evitar CSRF
Aplicar registro e validação segura do cliente
Utilize canais de comunicação criptografados
Defina prazos de validade curtos para tokens
Revogar tokens quando não forem mais necessários
Use tokens de atualização com moderação e cuidado
Siga as práticas recomendadas do OAuth para validação e redirecionamentosEmbora o OAuth 2.0 ofereça uma estrutura padronizada para autorização, as organizações devem tomar cuidado para mitigar vulnerabilidades por meio de implementação adequada, controles de segurança e políticas de acesso robustas. Protocolos adicionais, como o OpenID Connect, baseiam-se no OAuth para aumentar a segurança, demonstrando a necessidade de evolução contínua.

Indo além do OAuth 2.0

OAuth 2.0 tem sido um padrão importante para autorização e ainda continua sendo amplamente utilizado até hoje. No entanto, como um padrão com mais de 10 anos, o OAuth 2.0 está começando a mostrar sua idade e limitações diante das ameaças modernas à segurança. Aqui estão alguns dos principais motivos pelos quais o OAuth 2.0 pode não ser mais suficiente:

Projetado para desktop e Web, não para aplicativos móveis ou nativos - OAuth 2.0 foi criado na era anterior aos aplicativos móveis e nativos. Ele depende de redirecionamentos que não funcionam bem fora do contexto de um navegador da web. Isso pode criar vulnerabilidades de segurança.
Não criptografar tokens por padrão - Os tokens OAuth 2.0 geralmente são enviados sem criptografia, deixando-os abertos à interceptação. A especificação requer https para o fluxo de autorização, mas os tokens de acesso ainda podem ser transmitidos de forma clara.
Não há métodos integrados para validação de identidade - OAuth 2.0 se concentra na autorização e na delegação de acesso. Não verifica a identidade do usuário. Isso deixa espaço para ataques de personificação.
Riscos de reutilização e incorporação de token - OAuth 2.0 fornece autorização de uso único, mas não impede que o token seja usado várias vezes. Tokens com acesso mais amplo também podem ser incorporados em aplicativos, ampliando a exposição.
Não há exigência de prova de posse - Não há prova criptográfica de que a parte que usa um token seja o usuário autorizado pretendido. Isto cria um risco maior se um token for interceptado.
Padrões de criptografia limitados - OAuth 2.0 suporta apenas criptografia mais antiga, como SHA-1. Algoritmos modernos mais fortes, como SHA-256, não estão integrados à especificação principal.

À medida que as ameaças evoluíram, os recursos do OAuth 2.0 para proteção contra elas estão atingindo seus limites. Embora ainda seja amplamente utilizado, o OAuth 2.0 precisa ser ampliado e substituído por padrões de autorização mais robustos e modernos para determinados casos de uso. A exploração de protocolos como OpenID Connect, TLS mútuo e WebAuthn oferece opções para uma segurança mais forte no futuro.

Conexão OpenIDOpenID Connect é um protocolo de autenticação desenvolvido com base no OAuth 2.0 que fornece recursos de identidade adicionais. Com o OAuth 2.0, o servidor de recursos recebe um token de acesso que concede acesso, mas não fornece nenhuma informação sobre a identidade do usuário.

OpenID Connect permite que os clientes verifiquem a identidade do usuário por meio de autenticação com um servidor de autorização. Isso permite que o cliente obtenha informações básicas de perfil do usuário. OpenID Connect utiliza JWT (JSON Web Tokens) que contém declarações sobre autenticação do usuário, que podem ser repassadas ao cliente.

Alguns casos de uso importantes em que o OpenID Connect aprimora a segurança:

Logon único (SSO) - OpenID Connect permite SSO simples em vários sites e aplicativos. A autenticação é tratada pelo servidor de autorização do provedor de identidade, portanto, cada site não precisa lidar com sua própria autenticação.
Maior integridade - O token de ID contém declarações assinadas que foram verificadas com segurança pelo provedor de identidade. Isso fornece melhores garantias de integridade do que os tokens de acesso OAuth padrão.
Acesso ao perfil do usuário - O OpenID Connect fornece opcionalmente acesso às informações do perfil do usuário final, fornecendo ao cliente contexto adicional sobre quem é o usuário sem a necessidade de chamadas adicionais de API.
Maior confiança na identidade - Os padrões relativos ao uso de escopo, declarações JWT e criptografia fornecem maior confiança de que o usuário é quem ele afirma em comparação com o OAuth básico.

Então, em resumo, o OpenID Connect se baseia na autorização fornecida pelo OAuth 2.0 para também fornecer autenticação confiável e verificar a identidade do usuário. Para casos de uso como SSO e quando a garantia de identidade é crítica, o OpenID Connect é um protocolo mais seguro e robusto.

TLS mútuo para autenticação mais forte

O TLS mútuo fornece autenticação mais forte do que o TLS tradicional, exigindo autenticação bidirecional entre o cliente e o servidor. Com o mTLS, tanto o cliente quanto o servidor devem fornecer certificados para se identificarem antes de estabelecer uma conexão TLS criptografada.

Veja como funciona a autenticação mTLS:

O cliente inicia o handshake enviando ao servidor seu certificado de cliente. Este certificado é emitido por uma autoridade de certificação (CA) confiável e verifica a identidade do cliente.
O servidor então fornece seu próprio certificado de servidor ao cliente. Este certificado é validado na CA confiável para autenticar a identidade do servidor.- O cliente e o servidor negociam uma sessão TLS criptografada se ambas as partes validarem com êxito os certificados uma da outra. Isso cria um canal de comunicação bidirecional autenticado.
O cliente e o servidor agora podem trocar dados com segurança através do túnel TLS criptografado, sabendo que as identidades em ambas as extremidades foram verificadas.

O mTLS é mais seguro que o TLS padrão, que apenas autentica o servidor para o cliente. Ao exigir autenticação mútua, o mTLS evita conexões de rede não autorizadas, impedindo ataques man-in-the-middle.

Casos de uso em que o mTLS aumenta a segurança:

Proteger as comunicações entre microsserviços. O mTLS evita que microsserviços não autorizados ingressem na malha.
Autenticação para pods Kubernetes conectados internamente. O mTLS verifica as identidades dos pods que se comunicam dentro do cluster.
Protegendo a comunicação do dispositivo IoT. O mTLS bloqueia a comunicação máquina a máquina exigindo certificados de cliente.
Transações bancárias e financeiras. mTLS garante a integridade das transações entre sistemas financeiros.

A implementação requer suporte de cliente e servidor mTLS. Balanceadores de carga como o NGINX podem encerrar conexões mTLS e retransmitir o tráfego no modo TLS simples. Os SDKs do cliente facilitam a integração da autenticação mTLS em aplicativos móveis e da web conectados a serviços de back-end. Com bibliotecas e balanceamento de carga apropriados, as empresas podem implantar segurança mTLS em escala.

##WebAuthn/FIDO2

WebAuthn (Autenticação Web) e FIDO2 são padrões web emergentes que fornecem uma alternativa à autenticação tradicional baseada em senha.

O WebAuthn permite que sites registrem e autentiquem usuários usando criptografia de chave pública em vez de senhas. Isso é habilitado por meio de autenticadores como chaves de segurança ou biometria. O padrão foi criado pela FIDO Alliance e pelo World Wide Web Consortium (W3C).

FIDO2 é um conjunto de especificações técnicas que permitem métodos de autenticação sem senha usando credenciais seguras como chaves de segurança, biometria ou autenticadores de plataforma. É uma extensão do padrão FIDO (Fast Identity Online).

Aqui estão alguns dos principais benefícios do WebAuthn e FIDO2 em relação à autenticação de senha tradicional:

Maior segurança - As senhas podem ser fracas, reutilizadas, vazadas, roubadas ou sujeitas a ataques de phishing. O WebAuthn usa criptografia assimétrica (chave pública) para oferecer uma forma de autenticação muito mais forte e resistente a essas ameaças.- Melhor experiência do usuário - Não há necessidade de criar ou lembrar senhas. Os usuários simplesmente se autenticam com uma impressão digital ou chave de segurança, o que é mais rápido e fácil.
Custos reduzidos - As organizações gastam menos lidando com redefinições de senha, chamadas de suporte técnico e outros problemas relacionados a senhas que aumentam a sobrecarga de TI.
Proteção de privacidade - Com o WebAuthn, as credenciais originais (modelos biométricos ou chaves privadas) nunca saem do dispositivo do usuário. Isso protege a privacidade.
Independente de plataforma/dispositivo - WebAuthn funciona em desktops e dispositivos móveis. E não prende os usuários a uma plataforma ou dispositivo específico.

No geral, WebAuthn e FIDO2 representam um grande avanço em termos de segurança de autenticação e usabilidade na web. À medida que esses padrões ganharem adoção mais ampla, veremos menos dependência de sistemas vulneráveis baseados em senhas.

Conclusão

OAuth 2.0 tornou-se o padrão para autorização e autenticação para muitos aplicativos, fornecendo aos usuários uma maneira de conceder acesso limitado aos seus dados sem expor credenciais. No entanto, por ser um protocolo mais antigo, o OAuth 2.0 tem algumas limitações em relação à segurança, ao escopo de acesso e à experiência do usuário.

Os protocolos mais recentes têm como objetivo melhorar o OAuth 2.0 de várias maneiras:

OpenID Connect baseia-se no OAuth 2.0 para adicionar serviços de identidade, fornecendo verificação de identidade junto com autenticação e autorização. Isso ajuda a resolver algumas das vulnerabilidades de segurança no OAuth 2.0.
TLS mútuo fornece autenticação baseada em certificado de cliente e servidor, evitando ataques man-in-the-middle. Embora seja mais complexo de implementar, o TLS mútuo melhora a integridade e as proteções de privacidade em comparação com o OAuth 2.0 sozinho.
WebAuthn/FIDO2 usa criptografia de chave pública em vez de senhas para autenticação, fornecendo login resistente a phishing e à violação. Este protocolo pode substituir totalmente o OAuth para login em muitos casos.

No geral, embora o OAuth 2.0 tenha estabelecido as bases para uma autorização segura, sua idade é demonstrada em várias limitações herdadas. Os protocolos mais recentes baseiam-se no OAuth, mas abordam seus pontos fracos em relação à segurança, privacidade e experiência do usuário.

Para aplicações altamente sensíveis, como cuidados de saúde, serviços financeiros e gestão de identidades, o TLS mútuo e protocolos como o WebAuthn devem ser fortemente considerados para fornecer uma defesa profunda. Mesmo para aplicativos de consumo, aumentar o OAuth com OpenID Connect ajuda a garantir melhor integridade da identidade e autenticação do usuário.Fique ligado em APIRobots para obter mais insights e atualizações sobre este campo interessante. Não perca as oportunidades que as APIs podem trazer para o seu negócio. Contate-nos hoje em API Robots uma Agência de Desenvolvimento de APIs e vamos desbloquear todo o potencial das APIs juntos.