O que é OAuth 2.1?

O que é OAuth 2.1?

OAuth 2.1 é uma atualização proposta para o framework de autorização OAuth 2.0 . Envolve uma série de mudanças e recomendações para a especificação existente do OAuth 2.0, consolidando as melhores práticas e melhorias de segurança que foram amplamente adotadas na indústria ao longo dos anos.

As principais atualizações do OAuth 2.1 são:

1. Descontinuar implicit grant e Resource Owner Password Credentials (ROPC) grant devido a preocupações de segurança.
2. Impor o uso de Prova de Chave para Troca de Código (PKCE) para todos os clientes, incluindo clientes confidenciais (privados) .
3. Correspondência exata de URIs de redirecionamento .
4. Definição clara dos tipos de cliente (clientes públicos e confidenciais).
5. Requisitos de segurança para refresh tokens .

Descontinuação do implicit grant

O implicit grant foi projetado para aplicações de página única (SPAs) e aplicações baseadas em navegador que não podem armazenar segredos de cliente de forma segura. No entanto, seus riscos de segurança levaram à sua descontinuação: o grant retorna o access token no canal frontal (fragmento de URL), que pode ser exposto a atacantes através do histórico do navegador e cabeçalhos de referência.

OAuth 2.1 recomenda o uso do authorization code grant com Prova de Chave para Troca de Código (PKCE) para aplicações baseadas em navegador.

Descontinuação do ROPC grant

O ROPC grant permite que o cliente troque as credenciais do usuário diretamente por um access token. Foi projetado para aplicações legadas que não podem suportar o authorization code flow. No entanto, o grant apresenta riscos de segurança ao:

• Expor as credenciais do usuário ao cliente.
• Ignorar a tela de consentimento do authorization server.
• Limitar a capacidade do authorization server de impor outras medidas de segurança, como Autenticação multi-fator (MFA) .

OAuth 2.1 recomenda o uso do authorization code grant com Prova de Chave para Troca de Código (PKCE) para autenticação e autorização do usuário.

Imposição do PKCE para todos os clientes

Prova de Chave para Troca de Código (PKCE) é uma extensão de segurança para o authorization code flow que mitiga o risco de ataques de interceptação de authorization code. Envolve o cliente gerando um verificador de código e um desafio de código, e o authorization server verificando o desafio durante a troca de token.

Aqui está um diagrama de sequência simplificado do authorization code flow com PKCE:

Inicialmente, foi recomendado que clientes públicos usassem PKCE, mas o OAuth 2.1 estende esta recomendação para um requisito obrigatório para todos os clientes, incluindo clientes confidenciais (privados) .

Correspondência exata de URIs de redirecionamento

URIs de redirecionamento são usados pelo cliente para receber respostas de autorização do authorization server. OAuth 2.1 introduz um novo requisito de que o URI de redirecionamento usado na authorization request deve corresponder exatamente ao URI de redirecionamento registrado pelo cliente com o Servidor de autorização , incluindo o esquema, host e caminho.

Em algumas implementações do OAuth 2.0, a correspondência de URI de redirecionamento era flexível, permitindo correspondências parciais ou caracteres curinga. No entanto, essa flexibilidade pode introduzir riscos de segurança, como vulnerabilidades de redirecionamento aberto.

Definição clara dos tipos de cliente

OAuth 2.0 não define explicitamente os tipos de cliente. Você pode ver várias categorizações na indústria, como por nível de acesso (público vs. confidencial) ou por tipo de aplicação (aplicativo web vs. aplicativo móvel). Para o framework OAuth, não importa como o cliente é implementado (já que são mais sobre os atributos de negócios do cliente), mas o nível de acesso faz diferença nos requisitos de segurança.

Assim, OAuth 2.1 introduz uma definição clara dos tipos de cliente:

• Clientes públicos : Clientes que NÃO PODEM manter a confidencialidade de suas credenciais (por exemplo, SPAs, aplicativos móveis).
• Clientes confidenciais : Clientes que PODEM manter a confidencialidade de suas credenciais (por exemplo, aplicativos web do lado do servidor, aplicativos desktop nativos).

Requisitos de segurança para refresh tokens

Refresh tokens são tokens de longa duração usados pelo cliente para obter novos access tokens sem interação do usuário. Enquanto isso, eles também são alvos de alto valor para atacantes. Como clientes públicos não podem armazenar credenciais de forma segura, OAuth 2.1 especifica que o Servidor de autorização deve usar um dos seguintes métodos para proteger refresh tokens:

• Emitir refresh tokens restritos ao remetente .
• Usar rotação de refresh token para limitar a usabilidade e o tempo de vida dos refresh tokens.

OAuth 2.1 e OpenID Connect (OIDC)

Como o OpenID Connect (OIDC) é construído sobre o OAuth 2.0, as mudanças introduzidas no OAuth 2.1 também se aplicam ao OIDC. Por exemplo, todos os clientes OIDC devem usar authorization code flow com PKCE para autenticação e autorização do usuário.

Veja também

• OAuth 2.0
• Fluxo de código de autorização (Authorization code flow)
• Prova de Chave para Troca de Código (PKCE)
• Fluxo implícito (Implicit flow)
• OpenID Connect (OIDC)