Sobre as Cookies neste site Nossos sites requererem alguns cookies para funcionarem corretamente (obrigatório). Além disso, outros cookies podem ser usados com seu consentimento para analisar o uso do site, melhorar a experiência do usuário e para publicidade. Para obter mais informações, revise as opções de. Ao visitar nosso website, você concorda com nosso processamento de informações conforme descrito nadeclaração de privacidade da IBM. Para proporcionar uma navegação tranquila, suas preferências de cookie serão compartilhadas nos domínios da web da IBM listados aqui.
O que é OAuth (open authorization)?
Publicado: 29 de julho de 2024
Colaboradores: Gregg Lindemulder, Matt Kosinski
OAuth (autorização aberta) é um protocolo de autorização de padrão aberto, que permite que aplicativos acessem recursos hospedados por outros aplicativos ou sites em nome do usuário, protegendo suas credenciais.
O protocolo OAuth permite que os usuários concedam facilmente a esses aplicativos acesso aos dados de suas contas sem compartilhar suas credenciais de usuário.
Entre os exemplos mais comuns de Oauth estão os sites e aplicativos de terceiros que solicitam aos usuários "Fazer login com o Google?" ou "Permitir acesso às informações da sua conta?".
Além dos aplicativos da web, o OAuth também pode conceder acesso de recursos a APIs, aplicativos do lado do servidor, aplicativos nativos do sistema operacional, aplicativos e dispositivos móveis, como Smart TVs e dispositivos. Em alguns casos, não há nenhum usuário humano envolvido, pois o OAuth pode autorizar o acesso ao aplicativo em nome de uma organização ou conta comercial.
Saiba por que a KuppingerCole diz que a IBM é líder no fornecimento de soluções de autenticação corporativa maduras, escaláveis e seguras.
O OAuth oferece importantes benefícios de gerenciamento de acesso para usuários, desenvolvedores e empresas, mantendo os dados de login inacessíveis e limitando o acesso a outras informações confidenciais. Também facilita que os aplicativos acessem as informações necessárias da conta sem as vulnerabilidades de segurança do compartilhamento de credenciais do usuário.
Uma pequena equipe de desenvolvedores de software lançou o OAuth 1.0 em 2007. Essa primeira versão do protocolo foi projetada como uma alternativa à autenticação baseada na web, que exigia que os usuários informassem seus nomes de usuário e senhas a serviços de terceiros. No entanto, o OAuth 1.0 entregava fluxos de autorização apenas para sites.
Em 2012, a Internet Engineering Task Force (IETF) lançou o OAuth 2.0 como RFC 6749 e RFC 6750. Uma RFC (solicitação de comentários) é um documento da IETF que descreve protocolos de comunicação da Internet. A RFC 6749 é a estrutura principal do OAuth 2.0, e a RFC 6750 define como a estrutura utiliza tokens de acesso.
Esta versão atualizada do OAuth expandiu o protocolo para além dos navegadores da Web para incluir recursos de autorização para aplicativos, APIs e dispositivos. O OAuth 2.0 substituiu o OAuth 1.0 e agora é o padrão do setor.
Diferente de outras estruturas que dependem de nomes de usuário e senhas, o OAuth é um protocolo de autorização baseado em tokens de acesso.
Tokens de acesso são informações que determinam os recursos específicos que um aplicativo tem permissão para acessar. O protocolo OAuth define como cada componente de um processo de solicitação de autorização aprova, define e gerencia tokens de acesso.
Os tokens OAuth geralmente utilizam o padrão JWT (JSON Web Token) devido à sua capacidade de transmitir dados com segurança.
Os principais componentes da estrutura OAuth são:
- Proprietário do recurso
- Servidor de recursos
- Cliente
- Servidor de autorização
- Definir o escopo
É o usuário final que possui a conta que o aplicativo busca acessar, como uma conta do Facebook ou do Google.
O proprietário do recurso dá consentimento para que o aplicativo acesse determinados recursos protegidos nessa conta, como fotos ou dados pessoais. Em alguns casos, o proprietário do recurso pode ser uma empresa ou conta comercial.
Esse é o servidor que armazena os recursos protegidos em nome do usuário. O servidor de recursos aceita e valida os tokens de OAuth que recebe do cliente e, em seguida, apresenta os dados do usuário que o proprietário do recurso consentiu em liberar.
O cliente é o aplicativo, site, API ou dispositivo que solicita acesso.
Ele solicita autorização do servidor de autorização apresentando um ID de cliente. Em seguida, depois que o proprietário do recurso dá consentimento, o cliente recebe um token de acesso que pode ser usado para acessar recursos protegidos no servidor de recursos.
Esse é o servidor principal que aciona o protocolo OAuth. Ele opera dois pontos de extremidade para conceder acesso ao servidor de recursos.
O endpoint de autorização solicita que o proprietário do recurso forneça consentimento para recursos protegidos específicos. O endpoint do token então recebe a solicitação de token do cliente OAuth e gera novos tokens de acesso que concedem acesso aos recursos.
Os escopos são os parâmetros de acesso dos recursos protegidos no servidor de recursos.
Por exemplo, o proprietário do recurso pode ser solicitado a dar consentimento para acesso a dados como e-mails, arquivos ou fotos. O escopo restringe o acesso do cliente somente a esses itens.
Exemplo de fluxo de OAuth
Esta é uma visão geral básica de como um fluxo de OAuth pode funcionar:
- Jim (o proprietário do recurso) deseja permitir que um site de rede social (o cliente) acesse seus contatos de e-mail (o recurso).
- O servidor de autorização de e-mail solicita que Jim dê consentimento para esse acesso.
- Depois de receber o consentimento de Jim, o servidor de autorização entrega ao site de rede social um token de acesso.
- O site de rede social apresenta o token de acesso ao servidor de recursos que armazena as informações da conta de e-mail de Jim.
- O servidor de recursos reconhece o token de acesso e concede ao site de rede social acesso aos contatos de e-mail de Jim. Como o token de acesso inclui o escopo do consentimento do Jim, o site de rede social não pode acessar outros dados da conta do Jim.
O procedimento para entregar um token de acesso a um aplicativo é chamado de concessão de autorização ou fluxo de autorização. Há diversos tipos de concessões e fluxos de OAuth que podem ser usados com diversos tipos de aplicativos, dispositivos ou APIs, como:
- Código de autorização
- Proof Key for Code Exchange (PKCE)
- Credenciais do cliente
- Concessão implícita
- Atualizar token
Esse tipo de concessão normalmente é usado para aplicativos da web e aplicativos móveis.
Em um fluxo de código de autorização, o servidor de autorização apresenta um código de autorização único ao cliente. O cliente pode então trocar esse código de autorização por um token de acesso do ponto de extremidade de token do servidor de autorização.
Esse fluxo adiciona segurança extra à concessão do código de autorização para proteger os aplicativos contra ataques de injeção de código. Esses tipos de ataques podem induzir os aplicativos a executar códigos maliciosos que alteram a forma como eles operam.
O PKCE adiciona um "segredo do cliente" que autentica o cliente com o servidor de autorização antes que um token de acesso seja emitido. Como apenas o cliente legítimo tem o segredo, os agentes mal-intencionados não podem fingir ser o cliente e introduzir código malicioso.
Esse tipo de concessão foi projetado para situações em que nenhum usuário humano está envolvido, como processos automáticos, interações máquina a máquina e microsserviços.
Os aplicativos recebem acesso aos recursos do sistema de que precisam para executar funções, mas não aos recursos do usuário final. Por exemplo, uma concessão de credenciais de cliente pode permitir que um aplicativo de previsão do tempo acesse uma API para recuperar dados sobre a previsão mais recente.
Esse tipo de concessão oferece um fluxo mais simples para aplicativos da web em JavaScript. Diferentemente da concessão do código de autorização, o fluxo implícito não exige um código de autorização antes da emissão de um token de acesso.
Em vez disso, após o usuário dar consentimento, o token de acesso é incluído no Uniform Resource Identifier (URI) de redirecionamento que retorna o usuário ao aplicativo que solicita o acesso. O aplicativo recebe o token de acesso do URI.
Se um token de acesso tiver expirado, esse tipo de concessão entregará ao aplicativo um token de atualização que pode ser trocado por outro token de acesso. Sem um token de atualização, o usuário final precisaria novamente dar consentimento para que o aplicativo recebesse outro token de acesso.
A diferença fundamental é que o logon único (SSO) é um protocolo de autenticação de usuário e o OAuth é um protocolo de autorização.
O SSO geralmente utiliza um provedor de identidade (IdP) e a Security Assertion Markup Language (SAML), baseada na Extensible Markup Language (XML), para autenticar as identidades digitais dos usuários por meio de nomes de usuário e senhas.
A OAuth não autentica usuários, mas os autoriza a acessar recursos do sistema. As soluções SSO às vezes utilizam OAuth para oferecer aos usuários autenticados o acesso fácil a aplicativos e serviços em uma empresa.
O OpenID Connect (OIDC) é um protocolo de autenticação criado com base na OAuth 2.0. Trabalhando juntos, o OpenID Connect pode verificar a identidade de um usuário e, em seguida, a OAuth pode autorizar esse usuário a acessar recursos e serviços.
Soluções relacionadas
Proteja e gerencie as identidades dos clientes, da força de trabalho e privilegiadas em toda a nuvem híbrida, com integração com a IA.
Adicione contexto profundo, inteligência e segurança ao acesso do usuário a seus dados e aplicativos.
Proteja, controle e faça a mediação do acesso às suas APIs para protegê-las contra a intensificação das ameaças.
Recursos
Receba insights essenciais para ajudar suas equipes de segurança e TI a gerenciar melhor os riscos e possíveis perdas.
Conheça as táticas mais recentes de ataques cibernéticos para proteger melhor pessoal, dados e infraestrutura.
Em um sistema de computador, a autenticação ("auth" para abreviar) é o processo que verifica se um usuário é quem afirma ser.