A Microsoft anda mais de boa com o mundo open source, e isso, felizmente, respingou no ecossistema .NET.
Desde a chegada do ASP.NET Core, termos como JWT e OAuth 2.0 deixaram de ser coisa de hipster do linux da massa e passaram a fazer parte do vocabulário do desenvolvedor .NET (Pelo menos é o que se espera num mundo pós pandemia).
Mas vamos ser sinceros: Não é porque o termo se tornou buzzword comum que quer dizer que as pessoas saibam o que é.
Se você não tá familiarizado com essa sopa de letrinhas: JWT, OAuth, Bearer, Cookies e como eles se relacionam este post vai te ajudar a colocar os pingos nos i’s, e talvez te salvar de mais um sistema "meia-boca com token".
Entendendo as diferenças
Primeiro vamos entender os termos e como eles se relacionam.
OAuth2
OAuth 2.0 é chamado de framework de segurança. Bonito, elegante, padronizado… Parece até comercial de banco. É o que existe de mais moderno quando falamos de Autenticação e Autorização.
Qual o problema?
Ele cobra caro. Não em dinheiro (também, mas enfim), e sim em complexidade.
Configurar OAuth2 direito é quase um ritual satânico: precisa de especialista, documentação obscura e muito tempo pra entender o que está acontecendo.
Um especialista no mercado cobra caro e é extremamente dificil encontrar um maluco como teu pai que vos fala e que bate no peito e sabe o que tá falando. (mentira, só fiz meu marketing pessoal)
Mas sabe o que é o melhor de tudo isso? Provavelmente você nem precisa do OAuth2.
Na nossa cultura estamos acostumados a ranquear coisas:
- Goku tem 1 bi de poder, mas o Superman tem 1.1 Bi. 5 min sem perder a amizade, quem ganha?
- Uma Ferrari só vai até 300km/h, mas o FIAT Uno com escada alcança de 0 a 100 em 200ms e de final dá 400.
Legal, mas essa lógica NÃO se aplica aqui.
OAuth2 não é medidor de potência. Ele é um reflexo da arquitetura corporativa.
E perceba minha escolha de palavras ousadas, que nem faz muito sentido, mas eu quero te dar a impressão que é coisa de empresa grande, com 2.000 sistemas em produção, dos quais 1.999 são legados que ninguém tem coragem de desligar.
É nesse zoológico que OAuth2 faz sentido.
O que ele resolve?
Ele controla o acesso limitado aos dados de um usuário via HTTP, sem entregar a senha (obvio né).
Além disso, o OAuth2 define:
- O que pode ser compartilhado (através de escopes)
- Com quem esse compartilhamento pode rolar (clientes registrados)
- Tenta garantir que uma aplicação Web é, de fato, ela mesma, e não uma versão fake feita pelo sobrinho do seu chefe.
Resumindo: OAuth2 é o correio, entrega a autorização de um lado pro outro. Mas não se engane: ele não é o juiz, nem a polícia.
Na teoria bonita, você vai ler em mil lugares que OAuth2 não autentica ninguém (E de fato não faz). Só que na prática... esse limites são muito finos.
Toda implementação "real" de OAuth2 vem recheada de penduricalhos:
Autenticação interna, federação, integração com LDAP, login social, SSO e mais umas quinze buzzwords pra deixar o PowerPoint bonito.
Aí quem tá chegando nesse mundo olha e pensa: "Ah, isso é tudo a mesma bosta". Mas não é. Nem de longe.
E pra piorar um servidor de OAuth2 normalmente já vem atrelado ao OpenID Connect, esse sim, traz um servidor de autenticação de verdade. E pronto: mistura feita, ninguém mais sabe onde acaba o OAuth2 e onde começa o OpenID Connect.
Ele é tão complexo que existe até atores e cada um deles tem um papel bem distinto
- Users (os tapados)
- Roles (quem manda)
- Clients (quem pede)
- Resources (quem obedece... às vezes)
Quer saber mais? Respira, que isso é tema para outro post.
Para os mais familiarizados eu gosto de resumir o OAuth2 em: Um grande motor de geração de JWT. Se vc não tá familiarizado, esquece essa frase.
Bearer
Bearer não é nada
Bearer Authentication (também conhecida como Token Authentication) é um
schema de autenticação HTTP, definido na RFC 6750.
Formato padrão:
Authorization: Bearer <token>
Viu? Simples, direto... e totalmente vazio de significado por si só.
A RFC 6750 descreve o Bearer <token> como um token que deve ser seguro para para acessar recursos protegidos.
O token, nesse caso, é um comprovante de autorização, emitido por um servidor confiável (em teoria) e apresentado pelo client a cada requisição.
Ou seja, a RFC do OAuth2.0 não entra na guerra de qual tipo de token deve ser utilizado. Não diz se vai ser criptografado, se vai ser base64, se é um hash. Ela apenas resume: Um troço seguro. Apenas joga a bomba pro alto.
Quem manja de história, sabe que esse assunto deu pano pra manga. Esas novela de Bearer entre outros assuntos, é por causa da treta entre fornecedores (Big Techs) e acadêmicos (Que participaram do OAuth 1.0). E o que temos hoje é o resultado da pacificação dessa treta.
JWT
99.9% das implementações de OAuth2 do mercado usam o JSON Web Token (JWT) como Bearer Token.
Ele é definido por uma cacetada de RFC's, conhecido como JOSE (Javascript Object Signing and Encryption), é um padrão aberto para transmitir informações de forma compacta e segura entre duas partes. Tem muito critico? Tem, mas dai é tema pra outro post.
O JWT carrega claims, que são basicamente pares de key/value que:
- Identificam o usuário
- Definem permissões
- Controlam validade (expiração, quem emitiu...)
- E, infelizmente, às vezes carregam dados sensíveis que não deveriam estar ali.
O mais importante é entender que no Contexto de OAuth2.0 o JWT é uma escolha para representar o Bearer Token. Se você quiser saber mais sobre o que é um JWT, vamos pra outro beco porque senão a gente perde o foco desse conteúdo, dá uma olhada no meu post Conhece a familia do JOSE? Digo, JWT
Cookie
O velho guerreiro. Ainda útil. Mas cuidado pra não tratá-lo como um JWT disfarçado.
O cookie foi criado pra armazenar dados no navegador, um key=value enviado automaticamente pelo browser a cada requisição.
- É vinculado ao domínio/origem
- Pode ter data de expiração
- Pode ser protegido com flags como
HttpOnly,SecureeSameSite - É gerenciado pelo browser (o que é bom e ruim ao mesmo tempo)
No contexto de autenticação, muita gente tenta comparar cookie e JWT. Mas vamos deixar claro que não é porque você tem duas mães que uma delas é teu pai.
- Ambos podem transportar uma "prova de identidade" (Proof of identity)
- Não são intercambiáveis - Uma coisa é uma coisa, outra coisa é outra coisa.
Cookies funcionam melhor em aplicações monolíticas ou onde tudo roda sob o mesmo domínio e uma mesma API.
JWTs brilham em arquiteturas distribuídas (Integração de API's, apps mobile, microservices...), onde a independência e portabilidade do token são essenciais.
JWT ou Cookies?
"Qual usar? Depende. Qualquer outra resposta tá errada."
Cookies ainda funcionam bem em web apps tradicionais. Se sua aplicação vive num servidor só e tá tudo rodando bonitinho, segue com cookie.
Mas...
Se você tá num cenário com:
- Aplicativo mobile
- Microserviços
- Vários backends gritando uns com os outros...
Aí o cookie vira um pesadelo.
JWT é portátil, todas as linguagens de programação tem implementações baseadas na RFC do JOSE, por isso funciona bem em arquitetura distribuída.
Primeiramente: Segurança em primeiro lugar
"Ah, mas o sistema é só um MVP, não precisa de tanta segurança..."
Errou.
Segurança não é opcional, é pré-requisito. Mas minha experiencia (cartada de autoridade) mostra que projetos que não são corporativos, leia-se: Empresa com 1000 dev's e que fatura Bilhão, um OAuth2 é overkill. Há exceções? Tem, mas não é o papo agora.
E nunca se esqueça: "Não existe sistema 100% seguro. Só sistemas que ainda não foram atacados."
Não crie um sistema de autenticação
A menos que você seja especialista em segurança e acorde de manhã sonhando com RFCs, não inventa moda. Porque você vai se cagar todo no primeiro tema que é criptografia. E como diria eu mesmo:
"Criptografia feita por amadores é criptografia amadora."
Use frameworks testados, com comunidades ativas e manutenção contínua.
Ficar reinventando a roda só vai deixar seu sistema mais vulnerável, e seu time mais estressado.
Por que usar um framework conhecido?
Frameworks maduros seguem os padrões, já passaram por revisões, pentests, falhas e tudo mais.
Usar um framework confiável economiza tempo, dinheiro e cabelo.
Veja o exemplo abaixo de uma empresa que preferiu fazer na unha, e ficou com o sistema aberto como uma janela no verão:
Exemplo de falha real (dados mascarados)
O token nem expira, nem pode ser revogado. Um paraíso para invasores.
ASP.NET Core Identity
O ASP.NET Core Identity é a solução da Microsoft para autenticação e autorização. Suporta login via Facebook, Google, Conta Microsoft e até JWT e cookies.
Mas atenção: não é um servidor de autenticação.
Se você precisa de OAuth2, OpenID Connect e afins, procure outra solução.
Keycloak
Quer um servidor de autenticação completo, open source, com suporte real a OAuth2, OpenID Connect, SAML, LDAP, login social e ainda com painel de administração decente?
Então esquece de reinventar a roda e vai de Keycloak.
O Keycloak é mantido pela Red Hat, tem uma comunidade ativa, documentação decente (às vezes, meio esotérica, mas tá lá) e funciona de verdade em produção, desde que você não tente rodar num container com 128MB de RAM, claro.
Com ele, você tem:
- Authentication as a Service
- Single Sign-On / Sign-Out
- Controle de acesso por role, grupo, client e até por protocolo mágico se você souber o que tá fazendo
- Federation Gateway
- Login via Google, Facebook, GitHub, Apple, GitLab, Azure, etc.
- Suporte a multi-tenancy, multi-realm, multi-tudo
Quer seu próprio SSO, com painel bonitinho e controle total? Vai de Keycloak. Não inventa.
IdentityServer4
Já fazem anos que não recomendo, ótimo produto, mas só casos muito, mas muito especifico valem a penar usar ele. Pois ele permite você construir um Keycloack. E claro, lidar com a mesma dor de cabeça dele.
É um ótimo projeto. Os criadores são extremamento ativos nas conversas do Working Group da RFC do OAuth2 O problema é que você contrai todas as tretas de criar seu próprio servidor de OAuth2.
Equilibrio é a palavra chave
Ao criar um sistema de autenticação é preciso equilibrio.
Segurança demais espanta o usuário. Segurança de menos atrai atacante.
O segredo é o equilíbrio.
Agora que você já entendeu a base do JWT, OAuth2, Cookies e sabe que não é pra reinventar a roda. Seja feliz e se der problema chama teu pai aqui.
Fale conosco