Apenas uma ressalva sobre o vídeo: 1. OAuth2 não tem nada haver com autenticação, mas sim autorização. O access token do OAuth2 está apenas associado a autorização de uso de recursos. 2. JWT é apenas o formato do Token: Eu posso ter tokens de diferentes formatos, o JWT é o mais comum. (Tirado da RFC: Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements.) Resumindo: - OAuth2 é um protocolo para autorização. (como deverá ser o fluxo para autorizar acessos através de tokens) - JWT é um padrão aberto para representar tokens de forma segura. (formato do token) A. Posso usar apenas JWT? a. Pode, não preciso necessariamente usar OAuth2. Vc poderia usar um fluxo seu customizado onde o token gerado está nesse formato. B. Posso usar OAuth2 com JWT. b. Claro! OAuth2 será seu protocolo, enquanto os tokens usados nos fluxos serão conforme o padrão JWT C. Posso usar OAuth2 sem JWT então? c. Pode! Você pode usar outros formatos de tokens mais simples como chaves por exemplo. Mas aconselho usar OAuth2 com o JWT.

@LucasPedroso25

4 жыл бұрын

Resumiu tudo o que eu queria saber em um comentário.

@GiuDrawer

3 жыл бұрын

Outra coisa também meio falaciosa é sobre os cookies. "Cookie é legado"? Eu discordo, afinal com o httpOnly e MaxAge dá pra mandar o JWT em cookie e é uma estratégia de autorização bastante válida.

@gustavorobertosouza5099

3 жыл бұрын

Perfeito!

@IsaiasDanielRochaJunior

2 жыл бұрын

Comentário completo e objetivo!

O algoritmo do google está em outro nível. Ontem, andando de moto, do nada pensei em JWT. Hoje abro o youtube e é a primeira coisa que aparece kkkkkk Ótimo vídeo, Rocketseat é demais.

@rocketseat

4 жыл бұрын

🔮👀

@guilhermeluis7688

Жыл бұрын

JJJJJJJJJJJJJJJJJJJKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK

Às vezes eu sinto como se fosse mais uma entrevista do que um podcast... Ótimo vídeo de qualquer forma!

@henriquemartins8401

4 жыл бұрын

sim, o conteúdo continua sendo ótimo porém eu penso q os 3 q estão ali deveriam dar sua ""opinião"", não somente o Diego.

@CaioLesnock

4 жыл бұрын

@@henriquemartins8401 Poisé, assim como em qualquer podcast...

@lucasmallmann2411

4 жыл бұрын

Siim pensei que somente eu tinha essa visão. O vídeo continua sendo ótimo, mas tu falou bem. Parece mais uma entrevista do que um podcast

@rocketseat

4 жыл бұрын

Valeu pela dica, pessoal! 💜

Excelente bate-papo! E na minha opinião, não existe almoço de graça. Se vc quer regovar o acesso a qualquer momento daquele login na sua aplicação, sendo com Windows Forms, OAuth ou JWT, verifique a cada acesso as permissões na base de dados. "Há, mais isso torna mais lento..." Tune as suas queries... Entenda o seu ramo de negócios e tome a melhor estratégia! Pois no final das contas, a água vai bater no seu popóti (quem desenvolveu).

Cara, eu já estava a um tempo preso nesse assunto de autenticação e autorização, tentando entender e pensando muito em OAuth por ouvir falar. Muito obrigado por esse conteúdo, esclareceu bem para mim a diferença e o objetivo de cada um. E com isso acho que vou conseguir avançar melhor agora, pois eu acabava pensando demais em segurança e consequentemente acabava parando o desenvolvimento. Valeu!!😉👍

Ele simplificou este quisito nos primeiros 10min, o cara é fera!

Caramba kkkk tava pesando nisso Ágora!!!!!!!! Autenticação com JWT

Muita coisa hoje está ficando na mão dos DEVs e estão esquecendo de montarem uma pequena equipe de SRE e DevOps. Essa inversão de responsabilidades está expondo muitas irresponsabilidades por parte de DEVs ainda não maduros o suficientes, é aí que mora a insegurança, na falta de informação, na sobrecarga de demandas, pois na pressa de entregar acabamos ignorando varias coisas, principalmente a questoes de segurança...

Vaaaleu, Rocketseat!

Muito bom! RocketSeat não deixa nenhum comentário sem resposta! Empresa e equipe muito organizada!! Tbem posso dizer q a galera que assiste e comenta sempre tem um ótimo nível, e enriquece muito mais os conteúdos abordados! Parabéns e valeu galera!

@rocketseat

4 жыл бұрын

Vaaleu, Paulo! 💜 Fazemos tudo com muito carinho sempre! 💜

Parabéns TIMEEEE.... qualidade de conteúdo

@rocketseat

4 жыл бұрын

Valeu, Vinicius! 💜

Muito top! Parei o vídeo só pra comentar que quando eu cheguei em Portugal, e entrei no Facebook, a primeiro coisa que foi feita foi questionar o acesso fora do Brasil. Ótimo tópico levantado! 👏🏽👏🏽👏🏽

@rocketseat

4 жыл бұрын

Valeu, Jéfferson! 💜

Muito bom o Podcast! Sucesso galera.

@rocketseat

4 жыл бұрын

Valeu, Rogerio! 💜

Cara JWT é uma faca de 2 gumes, a segurança em si deve estar sempre no servidor, dá pra injetar código malicioso no JWT, como sql injection. O mais seguro ao meu ver é gerar o token jwt a partir de um par de chaves, pública e privada. Além de não gerar tokens que durem muito tempo e implementar o blacklist tokens.

Muito bom o conteúdo cara valeu #USAJWT

@rocketseat

4 жыл бұрын

Valeu o feedback, Eliakim! 💜

Eu partilarmente deixo jwt com tempo de expiração pouco, caso o usuario confirme que aquele dispostivo é de fato seu e de uso pessoal ai posso flexibilizar para aquela requisição um tempo de expiracao maior...

vc comentou sobre fazer pelo menos o basico, mas qual seria para vc o basico de segurança no backend para uma api exposta?

Muito bom o assunto. Obs: SSO geralmente eh feito com SAML!

@rocketseat

4 жыл бұрын

Valeu pela dica, e pelo feedback! 💜

Muito massa o conteúdo! Rocketseat sempre mandando bem! Apenas uns adendos: SSO geralmente é feito com Kerberos ou SAML... envolve um Identity Provider.....é diferente de OAUTH com certeza! Também precisamos ter cuidado pra não confundir Autenticação com Autorização! Falando nisso, seria interessante um video sobre RBAC no Backend Javascript Sobre invalidação de Tokens, utilizo uma estratégia no JWT onde cada vez que o user emite um token (faz login) eu incremento uma versão e armazeno no perfil do usuário. Quando ele faz logout ou se eu quero invalidar o token dele, eu simplesmente incremento a versão e o check de login não permite o token outdated. Assim evito necessitar um REDIS ou Mongo pra armazenar uma black list de tokens, que também não é muito escalável no longo prazo.... #USAJWT

@rocketseat

4 жыл бұрын

Valeu pelo feedback e pela sugestão, Eduardo! 💜

@osnirteixeira

4 жыл бұрын

na minha opinião, é perfeitamente possível utilizar SSO com OAuth, apesar do SAML e OAuth terem abordagens diferentes, como solução para "Login Único" são equivalentes, por mais que sejam diferentes(inclusive na implementação), pelo menos é o que acontece quando logamos em uma aplicação utilizando as credenciais de um serviço de terceiros como o Facebook, ou seja, o Login é unico. Acontece que em um Authorization Server de um servico OAuth, por debaixo dos panos existe também um Identity Provider. Na empresa que trabalho, utilizamos SAML 2.0 para acessar o Office 365 que esta na Azure e OAuth 2.0 para algumas outras aplicações que estão na AWS usando o AWS Cognito

@titocito

2 жыл бұрын

Mas nessa sua abordagem cada JWT que chega precisa ter sua versão conferida no banco, não é mesmo? Já que você vai precisar acessar o banco, por quê não usar autenticação/autorização baseada em cookie/sessão então?

@ebratz

2 жыл бұрын

@@titocito ponto bastante interessante! Desde minha postagem estudei alguma coisa sobre auth e atualmente trabalho da seguinte maneira... JWT short-lived que passo pelos headers (armazeno apenas in-memory no client side) e um refresh-token que armazeno no DB e no client-side via cookies HTTP only. E então trabalho com interceptors no client para buscar um novo access-token quando a requisição falhar. Assim consigo invalidar o refresh-token somente quando necessário e reduzo o número de operações de consulta do token ao banco de dados. Como minhas aplicações são muito pequenas, atende muito bem ao use-case... como tudo na TI, não há silver bullet e a maioria das respostas vão ser "depende"

@titocito

2 жыл бұрын

@@ebratz show! embora meu comentário pessimista sobre JWT, tou usando JWT da mesma forma que você comentou num backend de autenticação que arquitetei. O JWT nunca pode ser invalidado, o que pode é apenas o session token. Igual você disse, não tem bala de prata que serve pra tudo, mas é importante entender também todas as opções disponíveis. A boa é velha sessão pura com cookie tem muito valor. Se segurança é prioridade sessões devem ser usadas no lugar do JWT porque se torna obrigatório fazer verificações no banco em cada requisição, onde caberia então realizar invalidações.

Quando se trata de JWT o debate é longo, não tem bala de prata mesmo. O downside de manter uma blacklist ter que buscar dados do banco em cada request. O jeito é usar um banco de dados em memória como Redis pra diminuir o acesso ao banco e melhorar na latência.

@thiagodasilva9394

3 жыл бұрын

Mas a ideia do JWT é justamente ser stateless. Não que seja uma péssima prática fazer uma blacklist, mas a premissa do JWT é justamente vc n precisar fazer consultas para validar tokens. Basta colocar um tempo de expiração pequeno.

@andersondossantoscruz3685

3 жыл бұрын

@@thiagodasilva9394 sim, refresh tokens ajudam, mas tokens de 24 horas ou mais vc pode usar um banco como o redis não para validar, mas para cachear o único token válido gerado pro cliente. Se ele bater na sua rota de login 10 vezes e se logar as 10 vezes, ou você sempre mantém em cache apenas o último, e compara com o do header, pois terão outros 9 válidos, o tempo ainda não expirou dos 9, e vc precisa "invalidar" eles e considerar apenas o último. Ou vc vc terá esses 9 disponível para também serem usados enquanto não expiram. Eles ainda são válidos e vão passar em todos os seus guards. se o cara emitir mil, ele tem mil pra te atacar. Refresh tokens, onde o token tem vida curta e o refresh vida longa resolvem, mas ainda assim, tendo o refresh token na mão, o cara pode gerar quantos tokens ele quiser, até que o refresh expire, manter apenas um refresh também é válido. Se fizer isso não precisa de uma blacklist, pois vc tem apenas 1 registro do último válido e ele é o único válido que vai poder acessar. Pra não ficar consultando seu banco de dados em cada request, vc pode carregar eles no start da aplicação e jogamos pra um cache com o redis por exemplo. Assim vc pega eles da memória, e não faz leitura no banco. Pode ter 5000 tokens válidos gerados na maldade, só um vai passar

Ficou muito maneiro esse vídeo, era algo que sempre tive dúvida. Com relação a parte que ele citou sobre detectar atividades atípicas que nem no Facebook, existe alguma lib para express / adonis para isso?

@michaelpacheco7421

4 жыл бұрын

Victor, provavelmente deve haver algum middleware pro express que oferece esse tipo de serviço

@pedrocarbon

4 жыл бұрын

Victor, por padrão a expiração do token no adonis não vem ativo...sabe me dizer como ativar?

#USAJWT

Top

@rocketseat

4 жыл бұрын

Valeu, Ebner! 💜

Protocolo usado em SSO é SAML

#usajwt já ouviram falar de uma estratégia de autenticação de identificar como o usuário digita? TypingDNA

@rocketseat

4 жыл бұрын

Vamos dar uma olhada nisso, Vitor! Valeu 💜

#UsaJWT

Vai ter algum conteúdo sobre OAuth na nova versão do bootcamp?

@rocketseat

4 жыл бұрын

A princípio não, Marcelo! Mas abordamos JWT 💜

#usajwt

Para o PR: Não seria melhor terceirizar a autenticação da aplicação com soluções como o Keycloak?

@rocketseat

4 жыл бұрын

Vaaleu pela sua pergunta! #PR #diegorespondeaí 💜

Show de bola esse Podcast, inclusive na LaunchBase o Maykão utilizou o modelo baseado em Session. Será que rola uma bônus para implementação JWT no LaunchBase @Rocketseat ? #USAJWT

@rocketseat

4 жыл бұрын

Podemos pensar sobre, Kayo! 💜

Tem algum vídeo para #usajwt em seu canal ou que você indique?

@rocketseat

4 жыл бұрын

Temos vídeos sobre autenticação, mas nenhum específico sobre JWT. Vou anotar aqui como sugestão! 💜

Cara, gosto muito da Rocketseat, faço propaganda de vocês de graça, sou aluno do bootcamp, mas tem uma coisa que eu me incomodo nesse PodCast e somente nele, e não me entendam mal, eu gosto muito do PodCast, mesmo com o comentário que vou fazer, sempre assisto, inclusive esse foi ótimo para eu decidir sobre segurança em um projeto da empresa, mas nas lives eu sempre percebo a qualidade dos demais integrantes da Rocketseat, contudo, no PodCast, o foco fica sempre no Diego, que sem dúvidas nenhuma agrega muito valor, mas fica faltando a parte do debate, da empolgação, dos comentários polêmicos entende?, de toda forma quero agradecer muito a Rocketseat, vocês literalmente mudaram minha vida profissional e agradeço muito por isso.

@rocketseat

4 жыл бұрын

Poxa, que feedback mais massa, Jean! 💜 Valeu pela dica! 💜

@AtentoCC

4 жыл бұрын

Também acho. Acredito que o debate e os contra pontos são essenciais para construção de novas ideias e soluções.

@taveirinha1337

Жыл бұрын

Resumindo, estava faltando o advogado do Diabo nos poadcasts

Sinto que não foram abordadas as formas de dar refresh ao token... se de facto utilizar um refresh token não é seguro qual a melhor forma de manter um cliente logado com um JWT de curta duração?

@pedrocarbon

4 жыл бұрын

Pra mim, o refresh token é o usuário relogar...eu uso o JWT com data de 1 dia pra expirar...e no outro dia quando ele tentar fazer alguma requisição com o token dele que tá salvo no cache o meu backend vai vê que expirou e vai redirecionar ele pra tela de login.

@rocketseat

4 жыл бұрын

Quem sabe podemos falar disso num vídeo! Valeu, Hugo! 💜

Devo guardar a jwt no localstorage?

@rocketseat

4 жыл бұрын

Faala, Jean, tudo bom? Pensamos que é um tradeoff, porém na maioria dos casos o problema é com o client (usuário) independente da sua segurança, cookie é vulnerável a CSRF também independente se é httpOnly ou não... Todo sistema pode ser vulnerável, usando um jwt no localStorage você precisa tratar alguns campos pra evitar XSS também. Recomendamos: www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) www.owasp.org/index.php/Cross-site_Scripting_(XSS)

PIOR QUE DEIXAR VAZAR UM ACCESS TOKEN JWT É DEIXAR VAZAR SUA CHAVE DE CODIFICAÇÃO... ENTRAMOS EM OUTRA VISÃO, SERÁ QUE ALGUNS PROGRAMADORES TEM MATURIDADE PARA ENTENDER COMO USAR JWT DE MODO SEGURO? JWT É SEGURO, DEPENDE DE QUEM PROGRAMA E DEPENDE SE SUA EQUIPE DE SRE/DEVOPS É COMPETENTE O SUFICIENTE PARA GUARDAR CHAVES DO AMBIENTE DE PRODUÇÃO TANTO DOS DEVS COMO DA INTERNET.

qual o modelo do teclado que tu usa, diego?

@guilherme_capitao

4 жыл бұрын

Ele usa o Keychron k2.

@rocketseat

4 жыл бұрын

Um Keychron K2 com Brown Switch 💜

@mavibe__

4 жыл бұрын

@@rocketseat Muito obrigadoooo

Bom dia, estou com um problema na minha aplicação que não sei se realmente é um problema ou uma possível limitação de rodar a aplicação em modo de desenvolvimento. é o seguinte: - eu tenho um backend node js parecido com o desenvolvido na ultima semana onmistack, com o banco de dados Sqlite utilizando Knex para as migrations. (obs. estou utilizando o CORS para permitir acesso de qualquer origin) -Meu front-end é em react, consumo o back-end com o axios. -Tudo ta funcionando: consigo puxar o nome do meu usuario passando a id dele numa espécie de login inicial. O problema: quando eu executo yarn start no front-end, geralmente aparece dois links no console, um localhost:3000 e o outro utilizando meu ip de rede local. Por esse Ip local eu estava acessando pelo meu celular para deixar responsivo, o problema é que pelo celular não consigo fazer o "login", já no pc funciona normal. sempre dá Network error na requisição do axios. RESUMINDO: Minha página rodando no chrome do pc consegue consumir o backend, já a mesma página rodando em rede local pelo meu celular dá network error, sendo que para a navegação entre páginas funciona normalmente. Ja desativei o firewall pensando que seria o caso. no backend uso server.use(cors()); para permitir a conexão. Estou cogitando se seria por falta de certificação SSL, mas não tenho muita noção de como funciona isso. Se alguem souber me dizer o motivo, dessa disparidade entre acessar em localhost e acessar em rede local a mesma aplicação, fico no aguardo do seu comentário. Se precisar, meu email: makusdouglas@gmail.com repositório github da aplicação: github.com/makusdouglas/Tcc---Siex é uma aplicação que estou desenvolvendo para meu TCC. Desde já agradeço.

@markusdouglas6076

4 жыл бұрын

Meu código ta bem bagunçado, ainda vou organizar meu css e tudo mais.

@lucasbastos8019

4 жыл бұрын

Cara, acho que não funciona isso nao! Vc tem que servir um build do seu front p/ acesso WLAN e não pelo CRA normal sacou

@rocketseat

4 жыл бұрын

Fala, Markus! Você conhece a nossa comunidade aberta? Lá você pode tirar suas dúvidas 💜 entra lá! rocketseat.com.br/comunidade

t o p

@rocketseat

4 жыл бұрын

v a l e u 💜

Jwt é o json gerado por um server. O problema é o fluxo de autenticação, o que muitos ainda usam PasswordFlow (Inclusive vocês pregam nos exemplos). Este fluxo é totalmente inseguro.

@joaogabrielmp

4 жыл бұрын

Qual seria o método ideal?

@marcelodias1235

4 жыл бұрын

@@joaogabrielmp Varia do cenário, mas como no video eles não falaram...Vou imaginar que seja uma SPA, neste caso o melhor fluxo a adotar é Authorization Code Flow com PKCE

@diadetediotedio6918

2 жыл бұрын

Se for usar o password em requisições basta criptografar ou simplesmente hashear ele, em alguns casos é inevitável ter de passar esse tipo de credencial e desse modo a segurança é aumentada por várias vezes

Na minha empresa, quando o usuário se loga, a gente criptografa alguns dados específicos e manda como um token. Os dados de um JWT são visíveis a qualquer um que tem o token, e a gente não achou interessante.

@hitallo91

4 жыл бұрын

Por isso que o token deve ser secreto e seguro.

@rocketseat

4 жыл бұрын

Valeu pela dica, Rafael! 💜 É uma boa maneira também 💜

@gustavolol3

4 жыл бұрын

Não é recomendado colocar dados sensíveis no jwt, mas se quiser, ainda tem o recurso de criptografia, JWE.

@diadetediotedio6918

2 жыл бұрын

Se tiver criptografado não tem nenhum problema isso, você só precisa manter a chave privada segura. Se o cliente não pode manter uma chave privada segura não tem método de comunicação ou envio de dados ou armazenamento que consiga proteger ele.

Conteúdo muito bom, esclarecedor demais! Só poderia tomar cuidado com o cacoete de falar a todo momento: Vamos se dizer... vamos se dizer... vamos se dizer... vamos se dizer... vamos se dizer... vamos se dizer... vamos se dizer...

@rocketseat

4 жыл бұрын

Valeu pela dica e pelo feedback, Wagner! 💜

Troca essa música do início do podcast por favor, parece um pornozão essa aí kkkkk

impressão minha mas tirando o diego, os demais estavam, super, super nervosos ... nada contra, eu estaria até mais ... mas sinto que o diego faz isso pra a galera interna ir se expondo da maneira ''naturalmente" .......

Mas cara, Diego, tem uma coisa muito esquisita no seu argumento em defesa do JWT. O fato de sua aplicação ter que fazer uma blacklist ou whitelist de JWTs pra aumentar a segurança invalida totalmente o propósito do JWT, que é ser uma autenticação stateless, ou seja, não haver cadastros dele num banco de dados (Redis, como você deu exemplo). Se em algum momento da vida duma aplicação percebe-se que pra ter segurança é necessário armazenar JWTs no banco, a escolha do JWT foi incorreta. Nesse caso o correto é utilizar autenticação baseada em sessões, tipo cookies, que já são armazenados em memória no backend ou num banco tipo Redis.

Diego nao deixa quase os caras falarem, mt chato isso

Como sempre, a segurança prejudica o desempenho, e isso também impacta as entregas...

@rocketseat

4 жыл бұрын

Com certeza!💜

Nossa! Que confusão de conceitos nesse vídeo!!!! Estão confundindo a Autorização com a Autenticação. O JWT não te deixa autenticado, ele te deixa AUTORIZADO. Para você obter um JWT é que precisa se autenticar. Meu Deus!!!

#USAJWT

#usajwt

@rocketseat

4 жыл бұрын

💜

#USAJWT

#USAJWT

#USAJWT

#USAJWT

#USAJWT

#USAJWT

@rocketseat

4 жыл бұрын

💜