Quais são as principais diferenças entre a autenticação JWT e OAuth?

Eu tenho um novo SPA com um modelo de autenticação sem estado usando JWT. Muitas vezes me pedem para consultar o OAuth para fluxos de autenticação, como pedir para enviar 'tokens de portador' para todas as solicitações em vez de um cabeçalho de token simples, mas acho que o OAuth é muito mais complexo do que uma autenticação simples baseada em JWT. Quais são as principais diferenças, devo fazer com que a autenticação JWT se comporte como o OAuth?

Também estou usando o JWT como meu XSRF-TOKEN para impedir o XSRF, mas estou sendo solicitado a mantê-los separados? Devo mantê-los separados? Qualquer ajuda aqui será apreciada e poderá levar a um conjunto de diretrizes para a comunidade.

TL; DR Se você tiver cenários muito simples, como um aplicativo de cliente único, uma API única, talvez não seja interessante usar o OAuth 2.0, por outro lado, muitos clientes diferentes (baseado em navegador, móvel nativo, servidor) , etc) e seguir as regras do OAuth 2.0 pode torná-lo mais gerenciável do que tentar implementar seu próprio sistema.

Conforme declarado em outra resposta, o JWT ( Learn JSON Web Tokens ) é apenas um formato de token; define um mecanismo compacto e independente para transmitir dados entre as partes de uma maneira que possa ser verificada e confiável porque é assinada digitalmente. Além disso, as regras de codificação de um JWT também tornam esses tokens muito fáceis de usar no contexto do HTTP.

Por serem independentes (o token real contém informações sobre um determinado assunto), eles também são uma boa opção para implementar mecanismos de autenticação sem estado (também conhecido como Look mum, sem sessões! ). Ao seguir esse caminho e a única coisa que uma parte deve apresentar para obter acesso a um recurso protegido é o próprio token, o token em questão pode ser chamado de token de portador.

Na prática, o que você está fazendo já pode ser classificado como baseado em tokens de portador. No entanto, considere que você não está usando tokens de portador, conforme especificado pelas especificações relacionadas ao OAuth 2.0 (consulte RFC 6750 ). Isso implicaria, contando com o Authorizationcabeçalho HTTP e usando o Beareresquema de autenticação.

Em relação ao uso do JWT para impedir o CSRF sem conhecer detalhes exatos, é difícil determinar a validade dessa prática, mas, para ser honesto, não parece correto e / ou vale a pena. O seguinte artigo ( Cookies x Tokens: O Guia Definitivo ) pode ser uma leitura útil sobre este assunto, particularmente a seção Proteção XSS e XSRF .

Um último conselho, mesmo que você não precise usar o OAuth 2.0 completo, recomendo que você passe seu token de acesso no Authorizationcabeçalho, em vez de usar cabeçalhos personalizados . Se eles realmente são tokens de portador seguem as regras da RFC 6750, caso contrário, você sempre pode criar um esquema de autenticação personalizado e ainda usar esse cabeçalho.

Os cabeçalhos de autorização são reconhecidos e tratados especialmente por proxies e servidores HTTP. Portanto, o uso desses cabeçalhos para o envio de tokens de acesso aos servidores de recursos reduz a probabilidade de vazamento ou armazenamento não intencional de solicitações autenticadas em geral e, principalmente, de cabeçalhos de autorização.

(fonte: RFC 6819, seção 5.4.1 )

OAuth 2.0 define um protocolo, ou seja, especifica como os tokens são transferidos, o 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 em que o Cliente apresenta o token para o Servidor de Recursos: 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 (o primeiro estágio). É 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 de algo chamado Servidor de Autorização.

Portanto, a diferença real é que o JWT é apenas um formato de token, o OAuth 2.0 é um protocolo (que pode usar um JWT como um formato de token).

Primeiro, precisamos diferenciar JWT e OAuth. Basicamente, o JWT é um formato de token. OAuth é um protocolo de autorização que pode usar o JWT como um token. OAuth usa armazenamento do lado do servidor e do cliente. Se você deseja fazer logout real, deve usar o OAuth2. A autenticação com o token JWT não pode efetivamente desconectar-se. Porque você não possui um servidor de autenticação que controla os tokens. Se você deseja fornecer uma API para clientes de terceiros, também deve usar o OAuth2. OAuth2 é muito flexível. A implementação do JWT é muito fácil e não leva muito tempo para ser implementada. Se seu aplicativo precisar desse tipo de flexibilidade, você deve usar o OAuth2. Mas se você não precisar desse cenário de caso de uso, a implementação do OAuth2 será uma perda de tempo.

O token XSRF é sempre enviado ao 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 é protegido consigo mesmo. Portanto, o envio do token CSRF no JWT é desnecessário.

JWT (JSON Web Tokens) - É apenas um formato de token. Os tokens JWT são estruturas de dados codificadas em JSON que contêm informações sobre emissor, assunto (reivindicações), tempo de expiração etc. Ele é assinado para prova de violação e autenticidade e pode ser criptografado para proteger as informações do token usando abordagem simétrica ou assimétrica. O JWT é mais simples que o SAML 1.1 / 2.0 e é suportado por todos os dispositivos e é mais poderoso que o SWT (Simple Web Token).

OAuth2 - OAuth2 resolve um problema que o usuário deseja acessar os dados usando o software cliente, como aplicativos da Web baseados em navegação, aplicativos móveis nativos ou aplicativos de desktop. O OAuth2 é apenas para autorização, o software cliente pode ser autorizado a acessar os recursos em nome do usuário final usando o token de acesso.

OpenID Connect - O OpenID Connect baseia-se no OAuth2 e adiciona autenticação. O OpenID Connect adiciona algumas restrições ao OAuth2, como UserInfo Endpoint, ID Token, descoberta e registro dinâmico de provedores do OpenID Connect e gerenciamento de sessões. JWT é o formato obrigatório para o token.

Proteção CSRF - você não precisa implementar a proteção CSRF se não armazenar token no cookie do navegador.

Você pode ler mais detalhes aqui http://proficientblog.com/microservices-security/

Parece que todo mundo que respondeu aqui perdeu o ponto discutível de OAUTH

Da Wikipedia

OAuth é um padrão aberto para delegação de acesso, comumente usado como uma maneira para os usuários da Internet concederem sites ou aplicativos acesso a suas informações em outros sites, mas sem fornecer a eles as senhas. [1] Esse mecanismo é usado por empresas como Google, Facebook, Microsoft e Twitter para permitir que os usuários compartilhem informações sobre suas contas com aplicativos ou sites de terceiros.

O ponto chave aqui é access delegation . Por que alguém criaria OAUTH quando há uma autenticação baseada em id / pwd, apoiada por autenticação multifatorizada como OTPs e ainda pode ser protegida por JWTs, que são usados ​​para proteger o acesso aos caminhos (como escopos no OAUTH) e definir a expiração do Acesso

Não adianta usar o OAUTH se os consumidores acessarem seus recursos (seus pontos finais) apenas através de sites (ou aplicativos) confiáveis, que são novamente hospedados em seus pontos finais

Você pode acessar a autenticação OAUTH apenas se estiver OAUTH providernos casos em que os proprietários (usuários) de recursos desejam acessar seus (seus) recursos (pontos de extremidade) por meio de um cliente de terceiros (aplicativo externo). E é exatamente criado para o mesmo propósito, embora você possa abusar dele em geral

Outra observação importante:
você está usando livremente a palavra authenticationJWT e OAUTH, mas não fornece o mecanismo de autenticação. Sim, um é um mecanismo de token e o outro é um protocolo, mas uma vez autenticados, eles são usados ​​apenas para autorização (gerenciamento de acesso). Você precisa fazer backup do OAUTH com autenticação do tipo OPENID ou com suas próprias credenciais de cliente

encontre as principais diferenças entre JWT e OAuth

1. OAuth 2.0 define um protocolo e o JWT define um formato de token.

2. O OAuth pode usar o JWT como um formato de token ou acessar o token, que é um token de portador.

3. A conexão OpenID usa principalmente o JWT como um formato de token.

O JWT é um padrão aberto que define uma maneira compacta e independente de transmitir informações com segurança entre as partes. É um protocolo de autenticação em que permitimos que solicitações codificadas (tokens) sejam transferidas entre duas partes (cliente e servidor) e o token é emitido mediante a identificação de um cliente. A cada solicitação subsequente, enviamos o token.

Enquanto o OAuth2 é uma estrutura de autorização, onde ele possui procedimentos e configurações gerais definidos pela estrutura. O JWT pode ser usado como um mecanismo dentro do OAuth2.

Você pode ler mais sobre isso aqui

OAuth ou JWT? Qual usar e por quê?

A pergunta é comum, mas não é muito sensata. JWT é um tipo de token e OAuth é uma estrutura que descreve como distribuir tokens.

O que queremos dizer com "estrutura"? Apenas a sequência de solicitações e respostas, e os formatos dessas que podem e devem ser usadas para solicitar tokens. O OAuthv2 descreve "fluxos" ou tipos de concessão separados para diferentes cenários e possui extensões diferentes (como PKCE) para estender a segurança de fluxos específicos.

O resultado de uma solicitação de token por meio de uma concessão OAuthV2 é ... um token. Essa coisa é empregada como um "token do portador", o que significa que qualquer parte que possua o token pode apresentá-lo ao fazer uma solicitação de serviço da API (por exemplo, "qual é o saldo no meu cartão de valor armazenado?"). Como um token de portador, funciona como dinheiro vivo. Se você está segurando, você pode usá-lo. (Embora diferentemente do dinheiro vivo, um token não o use e perca. Talvez uma analogia melhor seja um ingresso para o dia inteiro no sistema de transporte público ou um ingresso para o dia todo na Disneyworld.)

O JWT é um tipo específico de token e o JWT pode ser absolutamente utilizado como um token OAuth Bearer. De fato, esta é a prática mais comum. À luz disso, "JWT vs OAuth" é uma comparação de maçãs e carrinhos de maçã.

Freqüentemente, as pessoas pensam que "token OAuth" sempre implica um token opaco - uma sequência aleatória de caracteres alfanuméricos que não contém significado inerente - concedido por um dispensário de token OAuth, que pode ser validado apenas pelo mesmo sistema de dispensário OAuth. Mas esse não é o único tipo de token OAuth. Um token opaco é um tipo de token; O JWT pode ser usado como um tipo diferente de token OAuth.

O JWT, por outro lado, não é opaco. O JWT não é um "ponteiro" ou referência a informações. Na verdade, ele contém muitas informações específicas, que podem ser extraídas e interpretadas por qualquer parte que possua o token. Como o JWT contém informações reais, um JWT pode ser grande; 300 bytes, 500 bytes ou mais, dependendo das reivindicações contidas nele e do algoritmo usado para assiná-lo. Quando as pessoas dizem que "o JWT é auto-validador", o que elas querem dizer é que qualquer detentor do JWT pode abri-lo, validá-lo e, em seguida, tomar decisões de autorização com base nas reivindicações nele apresentadas. Validar o JWT significa: verificar sua estrutura, decodificar a codificação base64, verificar se a chave está correta, verificar a assinatura e verificar se as reivindicações necessárias estão presentes no token, verificar a validade. Não é uma coisa simples, Em vez disso, é um processo de várias etapas, mas é claro que existem muitas bibliotecas em várias linguagens de programação que ajudam nisso e, claro, há a política do VerifyJWT que ajuda você a fazer isso dentro de um proxy da API do Apigee Edge. O ponto é que qualquer titular ou receptor pode verificar um token. Por isso, dizemos que o JWT suporta "Federação" - qualquer pessoa pode gerar um token e qualquer pessoa pode ler e validar um token.

reivindicações personalizadas. Os tokens JWT e OAuth opacos podem transmitir reivindicações personalizadas sobre o assunto. segurança. Ambos são tokens de portador. Ambos precisam ser protegidos como segredos. expiração. Ambos podem ser marcados com uma expiração. Ambos podem ser atualizados. O mecanismo ou experiência de autenticação. Ambos podem apresentar a mesma experiência do usuário.

Jwt é um conjunto estrito de instruções para a emissão e validação de tokens de acesso assinados. Os tokens contêm reivindicações usadas por um aplicativo para limitar o acesso a um usuário

O OAuth2, por outro lado, não é um protocolo, é uma estrutura de autorização delegada. pense em uma diretriz bem detalhada, para permitir que usuários e aplicativos autorizem permissões específicas para outros aplicativos em configurações públicas e privadas. O OpenID Connect, que fica no topo do OAUTH2, fornece autenticação e autorização. Detalha como várias funções diferentes, usuários em seu sistema, aplicativos no servidor como uma API e clientes como sites ou aplicativos móveis nativos podem se autenticar a cada outro

Nota oauth2 pode funcionar com jwt, implementação flexível, extensível a diferentes aplicações