OAuth2 é uma das especificações mais populares para autenticação de API atualmente, embora entender isso possa ser um desafio. Muitos aplicativos hoje são na verdade um front-end para uma série de chamadas de API. As APIs são necessárias para o funcionamento adequado de tais aplicativos, mas se você não as proteger, os agentes mal-intencionados podem exfiltrar dados, DDoS seus servidores ou abusar deles.

OAuth é uma das muitas soluções que você pode usar para proteger suas APIs e outros recursos. Ele permite que os usuários deleguem com segurança o acesso aos recursos sem compartilhar suas credenciais originais. OAuth2 (a versão do OAuth que este artigo abordará) existe desde 2012 como um padrão e é baseado em lições de outros padrões anteriores, incluindo OAuth1 e SAML.

Sendo um padrão, o OAuth se beneficia de muitas pessoas inteligentes trabalhando juntas de forma aberta. Como usuário deste padrão, você ganha todo o seu trabalho duro sem precisar contratá-los! Este trabalho inclui análise de segurança, onde o grupo considera constantemente diferentes vetores de ataque e fraquezas no protocolo e os melhora. Os membros do grupo também trabalham para dar suporte a casos de borda estranhos em escala, interfaces de usuário e conectividade de rede. Se você tiver um caso de uso de autenticação típico, o padrão OAuth quase certamente funcionará para você.

Se você precisar de funcionalidade principal, deverá estar coberto por quase todos os servidores OAuth. Mas se você precisar de funcionalidades especializadas, mesmo que sejam parte de um padrão, revise cuidadosamente a documentação de qualquer solução que esteja considerando.

Embora eu me aprofunde mais em como você realmente usa o OAuth para proteger uma API em seu sistema abaixo, incluindo exemplos de código, não abordarei determinados tópicos neste artigo. Alguns dos tópicos que serão omitidos incluem:

 

Cada especificação relacionada ao OAuth. Há muitos deles!

Todos os casos extremos que o OAuth e os padrões relacionados podem abordar.

Como usar o OAuth para acessar uma API de terceiros, como o Google. Este é um caso de uso relacionado, mas diferente o suficiente para que não faça sentido cobri-lo.

Ao concluir este artigo, você saberá mais sobre por que pode escolher o OAuth, quando usá-lo e algumas alternativas.

 

Por que usar OAuth para proteger suas APIs?

 

Ao usar o OAuth, você terceiriza a autenticação e a autorização do usuário para um provedor de identidade central (IdP). Os usuários entram no IdP e recebem permissões com limite de tempo na forma de um token de acesso. Esse token é apresentado a outros aplicativos, APIs e serviços.

 

Usar um serviço tão centralizado tem várias vantagens:

 

Um sistema com PII do usuário pode ser bloqueado e protegido mais facilmente do que muitos sistemas.

Assim como um banco de dados se concentra na retenção de dados com certas garantias, um IdP pode se concentrar na funcionalidade de login e fornecer uma interface bem compreendida.

Como um IdP é o local onde as decisões de autorização e autenticação são executadas, ele se torna um único local central para analisar, habilitar e desabilitar o acesso aos sistemas.

Quando todos os usuários se autenticam no IdP, você pode adicionar facilmente funcionalidades, como federação a outras fontes de identidade ou medidas de segurança, como autenticação multifator. Todos os aplicativos, APIs e serviços que aceitam tokens do IdP se beneficiam de funcionalidades adicionais sem qualquer alteração em seu código.

OAuth, que existe há mais de uma década, é onipresente. Existem clientes OAuth em quase todas as linguagens de programação modernas , e até mesmo em algumas menos modernas, como COBOL . Essa onipresença significa que, ao trabalhar com um servidor OAuth, você pode aproveitar as bibliotecas para realizar a integração rapidamente.

Ele foi estendido várias vezes para casos de uso especializados (chamados de perfis) e novos fluxos de autorização (chamados de concessões). O corpo de padrões por trás do OAuth, o grupo de trabalho OAuth IETF , oferece práticas recomendadas para tecnologias mais recentes, como aplicativos móveis ou dispositivos IoT.

Abaixo, discutirei os principais padrões que você deve conhecer, mas esteja ciente de que nem todo IdP implementa todos os padrões dentro do guarda-chuva OAuth. Exemplos de padrões que podem não ser implementados incluem:

 

A concessão de dispositivo , que permite executar um fluxo OAuth para um dispositivo com opções limitadas de entrada do usuário.

Cadastro dinâmico de clientes , que permite que os clientes se registrem com um IdP de forma automatizada, sem intervenção humana ou fora de banda.

MTLS , que permite que certificados X.509 mútuos sejam usados ​​para autenticação e para vincular tokens a clientes específicos.

 

Uma amostra das especificações

 

OAuth foi construído para ser estendido. Ao contrário das especificações anteriores relacionadas à autenticação, como SAML, que eram monolíticas, grandes e difíceis de implementar, o OAuth pode ser composto e extensível. Até mesmo a especificação principal foi entregue em duas RFCs, RFC 6749 (que cobre os fluxos) e RFC 6750 (que detalha o token).

Abaixo estão breves visões gerais dos padrões básicos, bem como alguns que são úteis em circunstâncias específicas. Você também aprenderá sobre padrões que ainda não estão codificados, mas vale a pena ficar de olho. Se você planeja implementar qualquer um deles, é sempre uma boa ideia mergulhar nos próprios textos RFC.

 

Padrões principais do OAuth

 

Esses são os principais padrões OAuth, embora nem todas as implementações precisem usar todos eles.

 

RFC 6749 e RFC 6750 : Conforme mencionado acima, eles compreendem o coração do OAuth. A primeira abrange os principais fluxos de autorização, chamados de concessões. Este último aborda como o token de acesso, o produto final de uma concessão, deve ser usado quando for um token de portador (na maioria das vezes, será um token de portador). Um token de portador não está vinculado a um cliente específico. Eu gosto de pensar em uma ficha de portador como uma chave de carro: qualquer um que tenha a chave pode ligar o carro. Da mesma forma, qualquer pessoa que possua um token de portador pode ter acesso a recursos protegidos por ele.

A RFC 7519 documenta um formato de token comum, JSON Web Tokens ou JWTs. JWTs são objetos JSON que contêm declarações (o que &eacut