Eu tenho um novo SPA com um modelo de autenticação Stateless usando JWT. Frequentemente me pedem para referir OAuth para fluxos de autenticação como me pedir para enviar 'tokens ao portador' para cada pedido ao invés de um simples cabeçalho de token mas eu acho que OAuth é muito mais complexo do que uma simples autenticação baseada em JWT. Quais são as principais diferenças, eu deveria fazer a autenticação JWT comportar-se como OAuth?
Eu também estou usando o JWT como meu XSRF-TOKEN para evitar o XSRF, mas me pedem para mantê-los separados? Devo mantê-las separadas? Qualquer ajuda aqui será apreciada e poderá levar a um conjunto de orientações para a comunidade.
**TL;DR*** Se você tem cenários muito simples, como uma única aplicação cliente, uma única API, então pode não valer a pena usar o OAuth 2.0, por outro lado, muitos clientes diferentes (baseado em navegador, celular nativo, server-side, etc), então aderir às regras do OAuth 2.0 pode torná-lo mais gerenciável do que tentar rodar seu próprio sistema.
Tal como referido noutra resposta, o JWT (Aprender os Tokens da Web JSON) é apenas um formato simbólico, define um mecanismo compacto e autónomo para transmitir dados entre as partes de uma forma que pode ser verificada e confiada porque é assinada digitalmente. Além disso, as regras de codificação de um JWT também tornam esses tokens muito fáceis de usar dentro do contexto do HTTP.
Sendo auto-contido (o próprio token contém informações sobre um determinado assunto) eles também são uma boa escolha para a implementação de mecanismos de autenticação apátrida (também conhecido como Olhar mãe, sem sessões!). Ao seguir este caminho e a única coisa que uma parte deve apresentar para ter acesso a um recurso protegido é o próprio token, o token em questão pode ser chamado de token portador.
Na prática, o que você're faz já pode ser classificado como baseado em fichas ao portador. Entretanto, considere que você're não está usando fichas portadoras como especificado pelas especificações relacionadas ao OAuth 2.0 (veja RFC 6750). Isso implicaria, confiar no cabeçalho HTTP "Autorização" e utilizar o esquema de autenticação `Bearer'.
Em relação ao uso do JWT para prevenir o CSRF sem conhecer detalhes exatos, é difícil verificar a validade dessa prática, mas para ser honesto, não parece correto e/ou válido. O seguinte artigo (Cookies vs Tokens: The Definitive Guide) pode ser uma leitura útil sobre este assunto, particularmente a seção XSS e XSRF Protection.
Um último conselho, mesmo se você não'não precisa de ir ao OAuth 2.0 completo, eu conselho vivamente a passar o seu token de acesso dentro do cabeçalho 'Autorização' em vez de ir com cabeçalhos personalizados. Se eles são realmente tokens portadores seguem as regras do RFC 6750, se não, você sempre pode criar um esquema de autenticação personalizado e ainda assim usar esse cabeçalho.
Os cabeçalhos de autorização são reconhecidos e especialmente tratados por proxies e servidores HTTP. Assim, o uso de tais cabeçalhos para enviar tokens de acesso a servidores de recursos reduz a probabilidade de vazamento ou armazenamento não intencional de pedidos autenticados em geral, e especialmente cabeçalhos de Autorização.
(fonte: RFC 6819, seção 5.4.1)
O OAuth 2.0 define um protocolo, ou seja, especifica como os tokens são transferidos, JWT define um formato de token.
OAuth 2.0 e "autenticação JWT" têm aparência semelhante quando se trata do (2º) estágio onde o Cliente apresenta o token para o Resource Server: o token é passado em um cabeçalho.
Mas "autenticação JWT" não é um padrão e não especifica como o Cliente obtém o token em primeiro lugar (a 1ª etapa). É daí que vem a complexidade percebida do OAuth: ele também define várias maneiras pelas quais o Cliente pode obter um token de acesso a partir de algo que é chamado de Servidor de Autorização.
Então a verdadeira diferença é que JWT é apenas um formato token, OAuth 2.0 é um protocolo (que pode usar um JWT como um formato token).
Primeiro, temos que diferenciar JWT e OAuth. Basicamente, o JWT é um formato simbólico. OAuth é um protocolo de autorização que pode usar o JWT como um token. OAuth usa armazenamento do lado do servidor e do lado do cliente. Se você quiser fazer logout real, você deve ir com OAuth2. A autenticação com o token JWT não pode fazer logout de fato. Porque você não'não tem um Servidor de Autenticação que mantenha o registro dos tokens. Se você quiser fornecer uma API para clientes de terceiros, você deve usar o OAuth2 também. O OAuth2 é muito flexível. A implementação do JWT é muito fácil e não leva muito tempo para ser implementada. Se a sua aplicação precisa desse tipo de flexibilidade, você deve ir com o OAuth2. Mas se você não'não precisa deste cenário de caso de uso, implementar o OAuth2 é uma perda de tempo.
A ficha XSRF é sempre enviada para o cliente em cada cabeçalho de resposta. Não importa se um token CSRF é enviado em um token JWT ou não, porque o token CSRF é seguro consigo mesmo. Portanto, enviar um token CSRF em JWT é desnecessário.