A Microsoft está mais aberta em relação ao que anda acontecendo no mundo open source e isso se reflete na comunidade .Net. Com a chegada do ASP.NET Core conceitos como JWT e OAuth2 tornaram-se assuntos mais frequente.

Não sabe o que é ou não tem certeza sobre as diferenças entre um e outro? Acompanhe este artigo, ele vai colocar os pingos nos i's.

Entendendo as diferenças

diferenca

OAuth2 é um Framework


OAuth2 é um framework de segurança (Autenticaçao e Autorização), pense num livro de regras. Ele descreve como usuários que através de clients terão acessos aos recursos protegidos pela aplicação.

Bearer


Bearer authentication (também conhecido como token authentication) é um Schema para autenticação HTTP (RC6750).

Authorization: Bearer <token>

O Bearer identifica recursos protegidos por um OAuth2. O <token> deve ser um string. Ele representa uma autorização do Server emitida para o client. Por sua vez, o client deve possuir mecanismos próprios para identificar e validar o Token.

JWT é um token seguro


O JSON Web Token (JWT) é o Token que acompanha o Bearer. Ele é um padrão aberto, definido pela RFC 7519. Estabelece uma maneira compactada para transmitir um objeto JSON, garante a segurança das informações e é utilizado para trafegar dados de autenticação entre dois clientes.

Ele é regido por um conjunto bem definido de instruções tanto para a emissão quanto para validação. O token possui as claims que serão usadas por um client para limitar o acesso do usuário.


O Cookie nasceu para armazenar dados arbitrários, possui um formato de Key-Value e é gerenciado pelo browser. Possui data de expiração e é vinculado ao domínio. Dentro do escopo de autenticação, a função dele é similar ao JWT, mas cuidado, não é uma alternativa, pois ambos possuem casos de uso diferente.

OAuth2 - Detalhes

OAuth

O OAuth 2 é um framework de segurança. Descreve como permitir o acesso, limitado, aos dados dos usuários em um client, através do protocolo HTTP.

Ele delega a autenticação a um server que hospeda a conta do usuário. E especifica como compartilhar as informações de autorização a outros aplicativos.

Ele é composto por Users, Roles, Clients e Resources.

Ir mais a fundo em suas features fica para um próximo artigo.

JSON Web Tokens (JWT) - Detalhes

O JWT e OAuth2 são as soluções mais implementadas para autenticação e autorização de Api's. O que você deve saber do JWT:

  • Oferecem uma maneira estruturada e stateless de guardar informações de autorização de um usuário.
  • Permite que a aplicação client guarde as permissões do usuário.
  • Podem ser encriptados e cryptographically signed para evitar adulterações.
  • Podem escalar horizontalmente.
  • Possibilita criar serviços verdadeiramente RESTful.
  • Expiração interna.
  • São independentes.

Um JWT possui o seguinte aspecto:

eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkJydW5vIiwiaWF0IjoxNTE2MjM5MDIyfQ.YDN0wJHLzyzmqdwycv4wgh-RMBwQR4C_0uehWmo_77ZrAB46YnPYmzJJ2Lb36GyyDXDwRP9Bt759hcVmUiGWEg

Há três seções nesta string, separado por ponto. Header, Payload e Signature.

O Header é um JSON que possui informações sobre o tipo de token e o algoritmo de criptografia utilizado.

Payload

Também é um objeto JSON, mas que contém as Claims do usuário. Elas são classificadas em três tipos Reserved, Public e Private

  • Reserved claims
    • Atributos reservados pela JWT, recomendados, que são utilizados na validação do Token. As mais comuns são iss (issuer), exp (expiration time), sub (subject), aud (audience). Para consultar todos, acesse rfc7519 - Section 4.1
  • Public claims
    • Informações que serão utilizados na aplicação para autorizar os recursos que o usuário tem acesso.
  • Private claims
    • Usadas para compartilhar informações entre aplicações.

Signature

Para criar a assinatura precisa codificar o Header e o Payload em base64, uma senha e utilizar o algoritmo de criptografia especificado no Header, após isso deverá assinar com a chave de criptografia.

Dessa forma previne ataques do tipo man-in-the-middle, garantindo que as informações dentro do token são confiáveis.

JWT ou Cookies ?

Cookies ainda são uteis, caso você possua uma única WebApp. mas caso seu framework não possui suporte a JWT, ou caso já esteja implementado. Num cenário destes não há motivos para uma troca.

Hoje em dia temos requisitos diferentes como aplicativos híbridos, SPA e Api's. Que podem depender de vários back-ends (divididos em servidores de autenticação de micro-services, bancos de dados, servidores de processamento de imagem, etc.). Nestes tipos de cenários mais elaborados, o cookie vai ser uma má decisão, pois a sessão que obtemos de um servidor não corresponde a outro servidor.

JWTs não usam sessões e são independentes, sendo ideais para arquiteturas de micro-services.

Primeiramente: Segurança em primeiro lugar

segurança

O titulo pode parecer redundante, mas é para chamar a atenção neste ponto. Depois de apresentar as diferenças entre os conceitos, seu dedo pode estar coçando para começar a implementar essas ideias, mas é preciso ter calma.

Segurança é algo que deve ser feito da maneira correta, então se você está aqui é porque tem esse cuidado.

Estar preocupado com as informações pessoais dos seus usuários, já é um sinal de que está fazendo a coisa certa. A GDPR acabou de chegar e este conteúdo é ainda mais relevante. Ainda que você tome uma boa decisão é importante saber que há um consenso geral sobre segurança: Não há sistemas totalmente seguro.

Há muitas soluções que oferecem implementações de autenticação e autorização, então nada de reinventar a roda.

Não crie um sistema de autenticação

A menos que você tenha certeza do que está fazendo e seja em especialista em segurança, não tente criar uma implementação própria, há um ditado que diz: Criptografia feita por amadores, são criptografias amadoras. Com um pequeno ajuste, essa frase se encaixa neste cenário: Uma autenticação feita por amadores, é uma autenticação amadora.

Existem técnicas de invasão da qual você não se preparou e que podem pôr seu sistema a prova, logo, está vulnerável.

Utilize algum framework. De maneira geral, elas já estão maduras o suficiente. Tem uma comunidade ou empresa por trás de seu desenvolvimento.

Por que utilizar um framework conhecido?

Os frameworks mais famosos implementam os conceitos corretamente. São maduros. Se sua equipe não está trabalhando num projeto OAuth, não tem porque utilizar o precioso recurso do seu projeto criando a roda. Frameworks estão em conformidade com o padrão. Veja o exemplo abaixo de uma multi-nacional que certamente não utilizou um framework. Gastou tempo e dinheiro e ainda assim estava vulnerável

Namespace, url e Bearer original foram substituidos.

O Token deveria ser emitido por Server, conter informações de validade. Se emitido por um terceiro, deveria ser possivel revogar o acesso, o que não ocorre neste cenário.

ASP.NET Identity Core

O ASP.NET Identity Core é a alternativa da Microsoft para autenticação e autorização. Possui suporte a provedores de login externo, como Facebook, Google, Conta da Microsoft, Twitter, etc.

Tem suporte a JWT e a Cookies.

IdentityServer4

IdentityServer4
IdentityServer4 é um framework open source, uma implementação oficial, certificada, do OpenID Connect. Garantindo que aplicações modernas, independentes da tecnologia, possam usar o servidor de Autenticação.

O Identity Server permite você fazer as seguintes implementações de Autenticação e Autorização:

  • Authentication as a Service
  • Single Sign-on / Sign-out
  • Access Control for APIs
  • Federation Gateway

Busque outras técnicas de autenticação

Combine a autenticação por usuário e senha com outras camadas de proteção como 2FA, E-mail ou Sms.

Equilíbrio

Um sistema com várias camadas de proteção, como User e Pass + 2FA + E-mail + Sms será impopular com o usuário. É preciso encontrar um equilíbrio.

Agora que você já viu o básico sobre OAuth2, JWT e os principais frameworks espero que te ajude a tomar uma decisão melhor.

Dúvidas? Vamos bater um papo!

Show me the code

Veja este artigo onde faço um exemplo com IdentityServer4 e Asp.net core 2.1

Referências