bom pessoal e agora a gente vai falar um pouco sobre autenticação e autorização em micro serviços tá eu não sei se em algum momento você já tinha pensado em como tudo isso funciona mas o grande ponto é que quando você trabalha com micro serviços não necessariamente você vai precisar fazer a autenticação de cada micro serviço. Por que eu estou dizendo isso? Porque dependendo da situação, do contexto que você está, o seu micro serviço já vai receber a autenticação, quer dizer, a requisição já autenticada. Quer dizer, a requisição já autenticada. Então, isso vai te poupar trabalho para que você faça apenas o serviço que você precisa e não fique necessariamente dependendo de processos de autenticação. Mas aqui existem todas as ressalvas e eu quero explicar aqui para você, baseado nessa imagem aqui que eu criei. Então, vamos lá a primeira coisa que a gente tem que pensar é que um usuário né ele vai sempre tentar mandar uma requisição e eventualmente aquela área aquela rota que ele está acessando ele vai precisar o que no final do dia se autenticar legal então o que pode acontecer nessa situação a normalmente tá quando você tem diversos sistemas você não vai querer é desenvolver um sistema de login para cada micro serviço então o que você vai fazer vai ser o seguinte o usuário vai é bater numa requisição aqui tá e essa requisição de autenticação ela vai acessar aqui diretamente um servidor de autenticação um servidor de identidade tá esse servidor de identidade o que que ele vai fazer ele vai verificar se as credenciais estão corretas tá e caso as credenciais estejam corretas ele vai retornar aqui para o usuário um toque tá um access token e também um aí de token eu não quero entrar nos detalhes sobre sobre openid connect o áudio tá e etc mas de qualquer forma tá esse toque nesse axis toque ele vai ser basicamente a chave que o usuário vai utilizar pra fazer a próxima requisição tá então a primeira requisição que ele vai fazer vai ser para se autenticar e conseguir ali um axis toque e também o aid to id token o id token em cima do open id connection que ele vai fazer normalmente ele vai dar inclusive as informações sobre o usuário tá não sobre o que necessariamente ele pode acessar tá hoje em dia tá é muito comum tá esse token ele ser no formato JWT, que é JSON Web Tokens, ou JOT em inglês, como o pessoal fala. E o que acontece? Ele com esse token na mão, ele consegue carregar quais são as informações do usuário e quais são roles, por exemplo, ou outras informações que você queira carregar ali no payload ali desse toque legal agora o que acontece é o seguinte nas próximas requisições de usuário fizer ele vai passar o que o jwt legal mas aí que está a grande sacada porque a gente tem algumas situações aqui é isso que eu quero que você preste atenção vamos lá primeira situação ele passa o JWT vai bater na API Gateway a API Gateway manda o cara para o servidor de identidade o servidor de identidade verifica se citou quem é válido e fala se está válido se for válido o que acontece a autenticação o processo de acesso continua e daí o que vai acontecer ele acessa diretamente os micro serviços agora perceba uma coisa aqui tá esses micro serviços eles não estão verificando a autenticação em nenhum momento porque porque a autenticação aqui já passou pelo e peguei tem tá e o ipa e gay ele tratou dessa intermediação com o servidor de identidade aqui para a gente. Então, os usuários finais não precisam necessariamente fazerem a autenticação. Então, essa é a situação número 1. Toda vez que o usuário passa o token, bate no servidor de autenticação. vez que o usuário passa o token, bate no servidor de autenticação, estando ok, o que acontece? Ele continua as requisições para os outros micro serviços. Agora, essa abordagem tem um problema extremamente grave, que é o seguinte, a cada requisição que o usuário faz, toda requisição, de qualquer forma, vai bater no servidor de autenticação. Então isso torna o quê? O servidor de autenticação, um ponto único de falha, faz com que o servidor de autenticação esteja sempre sobrecarregado. Então isso aqui para a gente é um baita problema tá é um problemão como que a gente consegue minimizar esses riscos aqui nesse caso o que que acontece o servidor de autenticação ele consegue emitir novos toques tá porque porque ele tem uma chave privada somente dele aqui. Mas para verificar se um token é válido ou não, basta ele prover para a gente uma chave pública. Com essa chave pública, a gente consegue verificar se o token do usuário foi realmente emitido pelo nosso servidor de autenticação. E se ele foi, a gente pode confiar nesse token. Então, o que a gente pode fazer aqui nesse caso é o seguinte, pegar a chave pública desse token e deixá-la disponível aqui no API Gateway. Então, o que vai acontecer? Toda vez que o usuário mandar uma requisição para qualquer micro serviço, ele vai mandar o token aqui, owt o j aqui tá e quando ele mandar a epa gateway ela apenas vai verificar se citou quem é válido se citou quem realmente foi emitido pelo servidor de autenticação porque agora ela tem uma chave pública e essa chave pública consegue validar se esse token é real ou não. Isso aqui sendo real, ele já encaminha as requisições para os microserviços para dentro da aplicação. Então esse aqui é o nosso primeiro ponto que você tem que sacar como que uma autenticação e autorização eu coloco também porque em relação a autorização você vai ter as roles na que esse cara pode realizar e daí baseado nisso cada micro serviço pode tratar diferente tá mas o nosso primeiro ponto aqui é que o usuário ele vai poder passar o token, a API Gateway valida se esse token é válido através de uma chave pública e encaminha normalmente a requisição para os microserviços. No próximo vídeo, eu quero falar um pouco sobre os efeitos colaterais que essa abordagem traz para a gente. Ela traz benefícios porque a gente não precisa acessar o servidor de autenticação toda hora, porque quem faz a validação da chave é o API Gateway, mas a gente também tem efeitos colaterais. A gente vai falar disso agora.