À medida que a tecnologia digital se torna cada vez mais predominante, proteger informações pessoais e empresariais é mais crucial do que nunca. A identidade serve como o principal limite de segurança para aplicações corporativas e de consumidor. À medida que os ataques cibernéticos e as violações de dados continuam a aumentar, proteger dados confidenciais tornou-se uma prioridade fundamental para indivíduos e organizações.
De acordo com o relatório de investigações de violação de dados da Verizon (2024), 86% das violações são atribuídas a credenciais roubadas, incluindo senhas, tokens OAuth/OpenID Connect e chaves de API. Esses tokens são normalmente usados para autenticar e autorizar usuários em vários sites, permitir que os usuários permaneçam conectados por um período prolongado e recuperar informações de perfil sobre o usuário que o site pode usar para personalizar sua experiência. As aplicações podem usar esses tokens para acessar recursos protegidos, como APIs e informações confidenciais.
Proteger esses artefatos privilegiados (tokens) tornou-se um requisito de missão crítica. A seguir, as práticas recomendadas que você pode implementar para proteger seus tokens OAuth e OpenID Connect.
Breve introdução sobre os tipos de tokens e aplicações OAuth/OpenID Connect
Primeiro, vamos abordar os diferentes tipos de tokens e aplicações OAuth e OpenID Connect.
Tipos de tokens
Tokens são credenciais digitais seguras usadas para verificar a identidade de um usuário e conceder acesso a recursos protegidos. O payload do token geralmente contém informações sobre o perfil do usuário, permissões e metadados, que são assinados criptograficamente para autenticidade e integridade.
Tokens de ID: Como o nome indica, os tokens de ID são usados para identificar o principal (ou seja, o usuário final). Eles contêm informações sobre o usuário e provam que o provedor OpenID autenticou o usuário com sucesso. O público-alvo para este token é o OpenID Client, ou seja, a própria aplicação.
Tokens de acesso: O OpenID Connect funciona em conjunto com o OAuth 2.0 para fins de autorização. Os tokens de acesso OAuth 2.0 delegam permissões à aplicação para chamar as APIs de back-end em nome do usuário. O público-alvo do token é a API de back-end (ou seja, o servidor de recursos).
Tokens de atualização: Os tokens de acesso e ID são de curta duração e expiram após um determinado período. Os tokens de atualização são concessões de longa duração que a aplicação pode usar para solicitar um novo par de tokens de acesso e ID do servidor de autorização. O público-alvo do token de atualização é o próprio servidor de autorização.
Tipos de aplicações
De acordo com a especificação do OAuth, os aplicativos podem ser classificados como confidenciais ou públicos. A principal diferença é se o aplicativo pode ou não armazenar credenciais com segurança (como um ID e segredo do cliente).
Aplicações públicas: Essas aplicações não podem armazenar com segurança segredos de cliente ou credenciais fornecidas por um servidor de autorização. Exemplos de aplicações públicas incluem aplicações modernas baseadas em JavaScript que são executadas no navegador (aplicações de página única) e aplicações nativas instaladas em dispositivos móveis e desktops.
Aplicações confidenciais: Por outro lado, as aplicações confidenciais podem armazenar e manter com segurança a confidencialidade das credenciais do cliente. Essas aplicações são executadas em um servidor seguro e, portanto, as credenciais não são acessíveis aos usuários finais. Exemplos de aplicações confidenciais incluem aplicações web tradicionais e aplicações back-end de servidor para servidor.
5 práticas recomendadas para proteger seus tokens
1. Use criptografia assimétrica para autenticação do cliente
A autenticação do cliente nos permite verificar a identidade do aplicativo cliente para evitar a representação do cliente e habilitar o acesso seguro aos recursos protegidos. Assim como as senhas são consideradas um fator fraco de autenticação do usuário, os segredos do cliente são um método fraco de autenticação do cliente, pois o segredo do cliente está contido no corpo da solicitação e depende de um segredo compartilhado.
Ao contrário dos segredos do cliente, as técnicas criptográficas assimétricas, como mTLS ou JSON Web Tokens (JWTs) assinados, conhecidos como private key JWTs, nunca são transmitidas pela rede, reduzindo drasticamente o risco de vazamento de chaves e ataques man-in-the-middle. A autenticação do cliente se aplica apenas a clientes confidenciais. Portanto, ao criar sua aplicação, considere usar um método de autenticação de cliente robusto, especialmente se estiver lidando com informações confidenciais. Saiba mais sobre os métodos de autenticação do cliente.
2. Adote o PKCE para clientes públicos
O aumento de aplicações móveis e baseadas na web provavelmente levou a um aumento nos clientes públicos. Como a autenticação do cliente não pode ser usada com aplicações de cliente público, o Proof Key for Code Exchange (PKCE) garante que apenas o cliente original que iniciou a solicitação de autorização possa trocar o código por tokens.
O PKCE garante que um invasor não possa resgatar um código de autorização roubado no endpoint de token do servidor de autorização. Embora o PKCE tenha sido inicialmente projetado para clientes públicos, o OAuth 2.1 recomenda o PKCE para clientes confidenciais, além da autenticação do cliente, pois oferece proteção adicional contra ataques de injeção e interceptação de código de autorização. Saiba mais sobre o PKCE com fluxo de código de autorização.
3. Implemente a prova de posse
A prova de posse é um método de restringir o uso de tokens de acesso OAuth a um cliente autorizado (aplicativo baseado em navegador). Isso pode ser alcançado de duas maneiras: vinculação de token baseada em mTLS no nível de transporte ou vinculação de token baseada em DPoP no nível da aplicação. Dadas as desafios de escalabilidade, capacidade de implantação e usabilidade do mTLS, demonstrar a prova de posse (DPoP) é a maneira recomendada de implementar a prova de posse. O DPoP representa uma melhoria significativa na segurança do OAuth 2.0, pois impede que invasores roubem e reproduzam tokens. Saiba mais sobre o OAuth 2.0 DPoP.
4. Considere seu processo de gerenciamento do ciclo de vida do token
Se comprometidos, os tokens de longa duração oferecem uma janela de oportunidade maior para atividades maliciosas que podem resultar em acesso não autorizado. Portanto, recomendamos atribuir aos tokens de acesso tempos de vida curtos e atualizá-los continuamente conforme necessário.
Para mitigar os riscos associados a tokens de atualização vazados, considere a rotação do token de atualização, que ajuda a girar o token de atualização com segurança após cada uso. A rotação de tokens de atualização pode ajudar a detectar a reutilização de um token de atualização, após o qual o servidor de autorização pode invalidar o token de atualização e todos os tokens de acesso emitidos desde que o usuário foi autenticado. Isso protege a aplicação contra comprometimento de token e ataques de reprodução. Saiba mais sobre a rotação de tokens de atualização.
Revogar todos os tokens quando um usuário sai de um aplicativo também é essencial. Quando um token é revogado, ele se torna imediatamente inválido, impedindo qualquer uso posterior desse token para acessar recursos protegidos. A revogação de token pode acontecer quando o usuário inicia um logout ou quando ocorre um evento inesperado, elevando o perfil de risco do usuário. Com a revogação global de tokens, os provedores externos de segurança e credenciais podem solicitar que um servidor de autorização revogue todos os tokens existentes de um usuário. Essa ação exige que o usuário se autentique novamente antes que quaisquer novos tokens sejam emitidos. Saiba mais sobre revogação global de tokens e Universal Logout.
5. Aplique o princípio do menor privilégio
As aplicações OAuth/OpenID connect devem ser projetadas e implementadas usando o princípio do menor privilégio para aumentar a postura de segurança da aplicação e minimizar os riscos potenciais. As políticas específicas da aplicação podem ser aproveitadas para garantir que apenas as pessoas certas possam acessar uma aplicação específica de um determinado local, tipo de dispositivo, perfil de risco, etc.
Os escopos OAuth podem ser usados para conceder permissões específicas em um token de acesso. Os escopos devem ser o mais granular possível para evitar que as aplicações solicitem permissões excessivas. Para casos de uso que exigem acesso refinado que muda dinamicamente, recomendamos modelá-los fora da estrutura OAuth. Isso ajuda a evitar que os tokens fiquem inchados com escopos excessivos e informações relacionadas a declarações. Saiba mais sobre políticas de login da aplicação, direitos e autorização refinada.
Embora este blog destaque alguns aspectos críticos do aprimoramento da segurança do seu token, o grupo de trabalho OAuth tem desenvolvido uma lista exaustiva de práticas recomendadas de segurança. Revise as especificações oficiais periodicamente para garantir que suas aplicações estejam em conformidade com as últimas tendências de segurança e padrões de identidade.
Tem perguntas sobre esta postagem do blog? Entre em contato conosco em eng_blogs@okta.com.
Explore mais Blogs de Engenharia perspicazes da Okta para expandir seu conhecimento.
Pronto para se juntar à nossa equipe apaixonada de engenheiros excepcionais? Visite nossa página de carreiras.
Desbloqueie o potencial do gerenciamento de identidade moderno e sofisticado para sua organização. Contate o departamento de vendas para obter mais informações.
