A proposta deste artigo é mostrar aos desenvolvedores alguns tópicos e dicas que normalmente não vemos nos tutoriais da Interwebs e apresentar uma forma de utilizar OAuth em uma aplicação baseada em microsserviço.

O “OAuth 2.0 Authorization Framework” é comumente confundido como uma forma de autenticação, no entanto, trata­se de um Framework de Autorização/Delegação que pode ser estendido para agregar mais funcionalidades, diferentemente do seu antecessor, o “OAuth 1.0

Protocol”, que era definido como um Protocolo de Autorização.

O significado da palavra “protocolo” está relacionado com “pacto” ou “acordo”, ou seja, é para ser utilizado da forma como foi definido. Já framework está relacionado com ”base”, “infraestrutura”, “esqueleto”, ou seja, algo para ser customizado/ estendido.

Vejo com frequência desenvolvedores implementando “na unha” funcionalidades de Authorization Server (nome dado a um OAuth Server, ou simplesmente AS) em suas aplicações, que basicamente seriam a exposição dos endpoints da especificação core do OAuth:

2: /token e /authorize.

Não que isso seja errado, mas atualmente é insuficiente; e muitas vezes, alguns pontos são esquecidos, como error codes, comportamentos específicos que a RFC sugere, controle de cache, encoding etc. Esses gaps acabam interferindo no bom funcionamento dos clients/libraries prontos de OAuth que poderão ser utilizados, o que irá acarretar no desenvolvimento de um client/library “próprio”.

Se pararmos para refletir, para implementarmos o mínimo de um Authorization Server, teríamos que seguir as especificações RFC6749 (The OAuth 2.0 Authorization Framework) e RFC6750 (Bearer Token Usage). Mas só isso não resolve os problemas de arquitetura e segurança atuais.

Vejamos, então, algumas RFCs que estendem as funcionalidades do OAuth 2.0 Authorization Framework:

• RFC 7009 Token Revocation: Essa RFC propõe um novo endpoint para o Authorization Server (ex.: /revocation), que possibilita a revogação de tokens que não estão mais em uso (access_tokens, refresh_tokens ou algum outro token emitido pelo AS). Um exemplo seria se o usuário fizesse um logout na aplicação (client), mudasse parâmetros na identidade ou desinstalasse o AppMobile; o cliente pode informar ao AS que os tokens provenientes daquela autorização já não são mais necessários.
• RFC 7662 Token Introspection: Essa RFC propõe um novo endpoint para o

Authorization Server (ex.: /introspect), que permite ao Resource Server verificar metainformações a respeito de um determinado token. Isso é muito útil na arquitetura de microsserviços, quando um access token é propagado para os microsserviços internos. Na primeira vez em que o microsserviço recebe o token, ele pode verificar junto ao AS se o mesmo ainda é válido, quais são os escopos de autorização do token, e-mail de quem autorizou etc.

• RFC 7797 (que substituiu recentemente a RFC 7519) JSON Web Token: Atualmente estamos ouvindo muito a respeito de JWTs ou JSON Web Tokens. JWTs são utilizados para proteger “claims/atestações” entre a comunicação de duas partes (um cliente e um servidor, por exemplo) com assinatura digital e/ou criptografia. O mais interessante é que sempre tivemos a possibilidade de utilizar assinatura digital e criptografia em nossas aplicações, mas o JWT trouxe uma grande quantidade de bibliotecas que abstraem e facilitam essas tarefas. Já existem diversas implementações customizadas de JWT sendo utilizadas em controles de segurança, como autenticação, e no contexto do OAuth faz todo sentido que o AS, em vez de gerar access_tokens “opacos”, passe a fornecer JWTs, o que permite, de forma controlada, que um resource server/microserviço faça instrospection (verificação) offline ou stateless.
• OpenID Connect Core (OIDC): É uma camada de identidade que funciona em cima do OAuth. Entende­se por identidade um conjunto de características sobre uma entidade (pode ser uma pessoa, um celular, um IoT etc.); na especificação do OIDC, essas características são claims de JWT. Um AS que suporta a especificação do OpenID Connect passará a emitir id_tokens adicionalmente aos access_tokens do OAuth.

As especificações acima citadas são as mais comuns de se encontrar em um Authorization Server. Vamos ver um exemplo de aplicação com uma arquitetura baseada em microsserviços e algumas características/ requisitos que ela possui referente ao uso de OAuth.

Propagação de Tokens: O mais comum é que o API Gateway funcione como um Resource Server para o mundo externo, já que ele recebe as requisições dos clients nos endpoints protegidos por OAuth, faz a validação do access_token e id_token recebidos, e repassa a requisição para o microsserviço interno correspondente daquela requisição. Muitas vezes, o microsserviço precisa ter mais detalhes sobre a autorização ou identidade de quem originou aquele request. Então, deve­se “propagar” os tokens para os microsserviços.

OAuth Filter: Cada microsserviço dentro da sua especialidade deve possuir um filtro/ middleware na camada REST para receber os tokens propagados pelo API Gateway ou até mesmo outro microsserviço. O filtro pode validar um token de duas formas:

• Fazendo introspection com o AS. Uma vez verificado, pode­se manter um cache da validação até a expiração do token.
• Validar JWT. Pode­se verificar a assinatura digital do JWT em todo request (stateless).

Além de verificar a procedência dos tokens, deve­se validar se os escopos e/ ou claims de identidade são suficientes e se o token não está expirado. Se a validação falhar, pode­se devolver um HTTP 401.

Serviços Legados: Imagine que a sua arquitetura possua APIs legadas que utilizam auth basic. É possível protegê­las com OAuth, utilizando um proxy reverso e um filtro de oauth implementado para o WebServer utilizado. Abaixo, alguns exemplos open source:

• Módulo de OAuth client para Apache 2x
• Módulo de OAuth client para NGINX

OAuth Server: Como vimos, desenvolver um Authorization Server que siga à risca as especificações e suas extensões é muito trabalhoso e algumas vezes até complexo e irá gerar algo a mais para manter além da própria aplicação. Há várias opções open source prontas disponíveis. Algumas podem ser configuradas de modo a atender plenamente a necessidade de uma aplicação. Outras necessitam da implementação de algumas interfaces, como Login, SessionStorage, TokenStorage etc. Abaixo, algumas ótimas opções:

• MitreID Connect
• Gluu Server
• Keycloak
• IdentityServer 3

Utilizando um Oauth server pronto, além de diminuir o tempo de desenvolvimento, teremos uma solução mantida pela comunidade e, assim que surgirem novas extensões, provavelmente elas serão incorporadas e, com isso, a aplicação se manterá atual sem muito esforço de desenvolvimento.

Bom, espero que com essas dicas e informações rápidas o leitor possa entender um pouco mais sobre o que está ao redor do Framework de Autorização OAuth e consiga decidir melhor que soluções usar e/ ou implementar.

***

Artigo publicado originalmente na Revista iMasters #19