Olá eu sou a Juliana Bezerra e nesse vídeo eu vou falar sobre um tema que gera muita dúvida entre as pessoas que é o walls e o open night se esse tipo de conteúdo te agrada já se inscreve no canal para acompanhar os próximos que vem por aí a motivação de tudo aqui é que as aplicações precisam logar o usuários principalmente para proteger o acesso a recursos que deveriam ser privados imagina por exemplo se alguém tivesse acesso ao seu perfil de uma rede social e pudesse alterá-lo não seria uma coisa legal né É por isso
que as aplicações precisam proteger acessos garantindo que apenas a pessoa autorizada possa acessar aquela informação específica do sistema que aqui a gente vai chamar de recursos Então a gente tem que proteger os recursos disponibilizados pelas aplicações na web E aí para poder garantir essa proteção aí de ponta a ponta na nossa aplicação a gente precisa fazer várias coisas armazenar e recuperar as credenciais do usuário inclusive Val Quando forem recebidas para permitir ou não acesso os recursos questão de segurança como eu falei duplo fator de autenticação recuperação de senha e várias outras coisas então tudo isso
aqui que precisa ser feito acaba trazendo uma segurança maior para as nossas aplicações e costuma ser algo que todo mundo precisa fazer toda aplicação normalmente acaba precisando disso aí implementado e aí a gente tem alternativas para implementar isso ou a gente faz tudo né a gente pode criar todas essas fitness de ponta a ponta na nossa própria aplicação que você deve estar imaginando Que dá bastante trabalho ou você pode delegar tudo isso aí é um terceiro Então esse terceiro já teria tudo implementado tudo testado e você estaria pegando carona com ele para fazer o uso
dessas funcionalidades E é isso que normalmente acontece quando tem aquela opçãozinha de logar com o Google ou com a Microsoft você coloca um par de credenciais e com ele você acessa vários mas vários sistemas daquele ecossistema da Google e da Microsoft por exemplo então ao usar esses sites terceiros parece uma alternativa bem interessante né e é por isso que normalmente essa alternativa escolhida nas empresas Mas beleza então como é que a gente faz para delegar tudo a um terceiro é aí que entra o alfa e o UOL com ele a gente consegue delegar todas essas
responsabilidades para provedores ou alfavedores que vão falar nesses mesmos protocolos como Google Microsoft Facebook e github então são caras grandes que já tem tudo testado que a gente pode confiar para fazer esse controle para nós tá bom só que aí entra A grande questão né O que seria esse e esse Open como é que eles conseguem delegar tudo isso para esses terceiros eles basicamente são protocolos então eles estabelecem regras estabelecem conceitos ritos que devem ser seguidos para que você possa se identificar num sistema e para aquele provedor terceiro ser capaz de considerar acesso a recursos
baseado nessa identidade que você proveu para ele então resumidamente é isso que eles fazem E aí com essa integração os provedores já vão ter tudo lá implementado então a gente vai poder se beneficiar daquelas funcionalidades que eu falei que precisariam serem implementadas mas para que você entenda como eles funcionam na prática em maiores detalhes a gente vai primeiro revisar algumas terminologias para a gente ficar alinhado a primeira é a questão de O que é autenticação e o que é autorização autenticação normalmente diz quem você é e a autorização diz o que você tem permissão de
fazer então para dizer quem você é normalmente você informa credenciais nome de usuário e a sua senha aí você está provando você é você e na autorização depois que você prova quem é você agora vamos ver o que você pode fazer então por exemplo em algum sistemas que tem papel de administrador só a pessoa com esse papel de administrador pode acessar alguns funcionalidades é importante também falar que às vezes a palavra autorização ou autorization é usada tanto para englobar autenticação como autorização em si né as permissões então a gente pode ouvir ela sendo usada para
significar as duas coisas e agora que a gente revisou essas terminologias a gente pode definir o uau como um protocolo que habilita uma aplicação terceira a obter acesso limitado a um serviço http então ele trabalha no escopo da autorização ele vai permitir acesso limitado dependendo das permissões daquele usuário dos papéis dele é um recurso hospedado no serviço http e para fazer isso para alcançar isso é aí que entram os papéis dentro do ele estabelece papéis que tem responsabilidades aqui para entregar essa autorização seguindo esse protocolo Então a gente tem o risociona que é o dono
do recurso o Resort server que é onde está o recurso o autorization surver que é que aquele que concede acesso ao recurso e o clide que solicita acesso ao recurso Não se preocupe se você ainda não entendeu você vai agora ver um historinha para entender como é que ele se falam tá Como é que esses componentes se falam para entregar essa autorização Então vamos lá vamos começar a conversar tudo começa com ele ele normalmente como ele é o dono do recurso Ele é usuário final ele é você que tá tentando acessar o seu recurso protegido
em barra recurso por exemplo E aí quando você faz isso normalmente você Tá acessando uma aplicação aplicação terceira e essa aplicação é o cliente e ela vai dizer vai retornar para você né Beleza você quer acessar isso aqui mas esse recurso é protegido Então você precisa me autorizar para acessar em seu nome e aí o que que ela faz ela te encaminha para uma espécie de superior dela para que você possa se identificar e confirmar que você concedeu os acessos necessários para essa aplicação cliente e aí você concorda né não tem muito que fazer e
se apresenta aqui para o as que é o autorization serve como você já se registrou faz um tempo nele ele tem as suas credenciais então ele vai lembrar de você mas é claro né você pode dizer para ele que você é você mas você precisa provar e para provar ele vai te pedir suas credenciais Então esse cara aqui é como se fosse o Google o Facebook ou o idp que é o idêntico o provedor de identidade que você usa ele tem as suas credenciais cadastradas e se você fornece corretamente ele vai te reconhecer E aí
quando você fornece essas credenciais você também seleciona quais acessos você vai permitir para o cliente que está falando em seu nome o cliente normalmente sugere alguns mas você escolhe quais acessos você vai conceder E aí sim agora que você fornecer os credenciais o autor existe um server válida tudo isso e entrega para você um token de acesso para que o cliente use então perceba que uma coisa bem importante você alugou uma vez forneceu suas credenciais para autorization server o cliente não viu as suas credenciais não conhece o seu usuário e senha e é por isso
que ele te encaminhou para o autorização server para que você forneça para ele suas credenciais e ele nem saiba que elas existem o que que ele vai usar na verdade para os próximos acessos o token de acesso gerado exatamente com esse fim permitir o acesso sem credenciais Agora sim contou quem retornado para aplicação Clint ela pode falar com URSS que é o Resort server e pedir para acessar o recurso passando o token de acesso esse resour server ele sabe dizer que o token é válido porque porque se estousses de acesso eles são assinados e essa
chave de assinatura Ela é conhecida pelo emissor do Token que é o autorization server então o que que o rio Só serve faz ele pergunta olha autorização server esse token é válido ele conhece o emissor do Token então ele Pergunta para ele e aí se o autorização server validar ele considera o Toke inválido e retorna O recurso para o cliente que é esse o caso então o cliente pode retornar os dados recebidos para o ressalcione E aí acaba nossa história Então essa é basicamente a comunicação que acontece dentro do Alfa dentro desse fluxo desse protocolo
de autorização o cliente vai solicitar a autorização para acessar o recurso para o rei só funciona os concede a autorização e aí o autorization server é capaz de retornar um token de acesso E aí com esse passo ele pode acessar os dados os recursos protegidos que o Resort Warner precisa visualizar no computador ou no celular Enfim no dispositivo que ele tá acessando essa aplicação cliente e aí simples né acredito que deu para entender bem agora porque existem todos aqueles papéis dentro do Olaf se foi o caso já deixa o like aí não se esquece por
favor para dar essa força para o canal e vamos agora para a próxima etapa vamos falar um pouquinho desse token de acesso Imagino que você deve ter ficado com curiosidade para saber que tipo de Tom que a gente pode usar e existem dois tipos basicamente o excesso token Então bora lá token que é o token de acesso basicamente É ele que vai conceder acesso aos recursos protegidos e esse token por sua vez ele é compreendido pelo reforço Seven não diretamente por ele só serve fala com autorização perguntasse aquele token ali é válido ou então ele
conhece a chave que foi usada para assinar o token E aí ele não precisa ir lá no autorization server também é outra forma de trabalhar o importante é saber que o Resort server sabe identificar que o token é válido ou não E esse token ele pode ser de dois tipos ele pode ser o famoso jwt ou um token opaco e começando pelo jwt que talvez seja o mais famoso ele é pronunciado Jotta em inglês e significa Jason web token então é um token em formato de som que é um formato que você já deve conhecer
também esse formato aqui desse payload e a grande característica dele é que ele pode ser lido Então você vai ter um string desse tipo aqui que vai ser o conteúdo desse idiota e aqui dentro a gente tem encapsulado essa informação aqui informações por exemplo do próprio usuário aqui também tem outras informações Mas o foco que eu estou dando aqui informação do payload que a informação dos dados do usuário então com esse token você pode obter informações de quem está logado e como token assinado ninguém pode simplesmente inserir informações lá a pessoa precisa conhecer a chave
que da assinatura a chave privada né que a gente não compartilha com ninguém para ser capaz de alterar o conteúdo desse token sem validá-lo Então é isso que torna ele uma forma interessante e segura de autorizar o acesso e o outro tipo de token que existe eu token opaco e o nome dele já diz tudo A grande diferença é que o conteúdo dele não pode ser lido pelos clientes só o emissor sabe como ler aquilo ali porque ele é basicamente uma chave que aponta para um conteúdo que está salvo em algum mecanismo de persistência e
esse token É bem interessante para ser usado quando a gente não pode expor o conteúdo os dados do usuário por exemplo autenticado quando o conteúdo é sensível então a gente pode usar esse tipo de token ao invés do idiota Quando a gente precisa preservar os dados do usuário autorizado e finalmente a gente tem agora o refresh token aqueles dois tipos o George e o opaco são tipos do Access token ele pode ser desses dois tipos e uma vez que o access token ele tem uma validade ele inspira a gente precisa de uma forma de obter
novos token sem precisar logar no sistema novamente é por isso que algumas aplicações têm suporte ao uso de refresh token por baixo dos panos condutor de acesso inspira o token de atualização vamos dizer assim é usado para solicitar um novo token de acesso e por ele ser apenas um token necessário para gerar outros tokens ele normalmente é opaco Tá ok ele não tem conteúdo lá dentro que precisa ser lido e aí com esse tom quem a gente consegue gerar outros tokens de acesso inúmeros tokens de acesso falando lá com o autorization serve Então já dá
para ver que esse token aqui nunca pode ser vazado né Ele é um perigo porque alguém com esse token pode gerar inúmeros processo Então beleza falamos sobre os tipos de token que existem aqui que podem ser usados com o protocolo Alpha mas agora o que que esse usuário vai poder fazer Quais são as permissões dele é aí que entra um outro conceito dentro do oaf que são os escopos os escopos então eles têm a ver com papéis ou permissões associadas a um token de acesso Ele eles dizem o que que um usuário pode fazer você
já deve ter visto aquelas telas que informam Ah uma aplicação está pedindo permissão para ler e-mails Acessar lista de contato e aí você escolhe permitir ou não essas operações pela aplicação terceira o nome disso aqui dentro do Alf é escopo e é uma forma de restringir o acesso a recurso sensíveis que só podem ser acessados por pessoas autorizadas Então esse é mais um conceito aqui dentro do Office e agora a gente vai chegar no conceito que talvez seja o que gere mais confusão Como funciona o fluxo de autorização basicamente a gente tem vários e a
gente chama eles de Grant types são formas de autorizar o usuário no sistema seguindo o protocolo Alfa Então a gente tem quatro tipos aqui que são o password o Clinton e o que varia entre esses quatro basicamente as credenciais utilizadas e a comunicação entre aqueles papéis estabelecidos pelo horta Então vamos ver aqui em detalhes cada um desses Grand Styles vamos começar pelo password a gente vai ter a figura do resort on né que é o dono do recurso Ele tá acessando a aplicação cliente e a ideia aqui que nessa aplicação cliente você informe as suas
credenciais E aí a aplicação cliente teria suas credenciais e acessar os recursos protegidos falando com autores deixam server ela passaria seus credenciais receberiam token de acesso e usaria esse token de acesso daqui para frente essa aqui seria a Rex são feita para o autorization server então requisito para usar esse Type aqui clientes sejam super confiáveis você tá dando sua senha seu usuário e senha para o cliente imagina se você é do banco e esse cliente não for confiável a aplicação poderia transferir todo seu dinheiro por exemplo então é por isso que esse fluxo aqui a
gente costuma evitar nas nossas aplicações a não ser claro né que ele seja a única alternativa que o cliente que essa aplicação cliente seja super confiável Mas normalmente a gente evita esse cara então beleza o que mais a gente tem aqui de Grant Type a gente tem o client produtions e a natureza que desse fluxo é própria para serviços falando com serviços Porque você só tem as credenciais desse cliente dessa aplicação cliente então aqui eu tenho uma aplicação falando com outra aplicação que está protegida por um autorization server E aí para poder ter o acesso
para ter o token de acesso eu passo as credenciais desse cliente que estão cadastradas no autor de texto server com uma aplicação parceira dele e ele confiando nessa aplicação ele funciona o excesso doken essa aqui seria a requisição feita para obter esse token de acesso eu tô autenticando aqui com as credenciais do cliente por isso que vão aqui nesse header de autorization E aí eu informo esse tipo de Grand Spy esse aqui a gente usa bastante esse tipo de fluxo de autorização mas ele é bem específico para serviços falando com outros serviços agora a gente
tem um caso que é mais usado para Spa esse aqui é um dos mais comuns e é um dos mais complicados de entender porque tem muitas etapas aqui a gente tem front-end Spa né uma 5pg application falando com back end que precisa ser protegido então a gente usa normalmente nesses casos o autorization Code esse Grand Style Então vamos seguir aqui a sequência da comunicação O que que a gente faz primeiro aplicação cliente ela vai passar aqui o ID desse cliente e uma URI de redirecionamento e ela vai passar isso através de um user agente esse
cara aqui seria o navegador por exemplo Então tá bom passei aqui a minha meu adido cliente que tá cadastrado na autorization server é a minha credencial só o ri de redirecionamento que normalmente é um ri que aponta para mim aplicação cliente então aqui eu chegou essa informação aqui na altura eles deixam server E aí por causa dela ele vai pedir ao autenticação para esse cliente aí então vai ser retornado aqui por isso só funciona e fornecer as credenciais dele o usuário e senha e aí quando ele faz isso a gente chega no Passo 3 que
é o autorização serve receber essa autenticação feita pelo Resort Honey confirmar que ele existe e retornar um código de autorização temporário intermediário aqui que vai ser enviado através dessa URI de qual Beck aqui URI de redirecionamento que está implementada nessa aplicação cliente e aí com essa URI o meu cliente é capaz de obter autores Station code e passar ele para obter o essas token finalmente passando novamente uma URI de redirect que tá cadastrada aqui no atualization server E aí com isso autorization server passa o excesscod através desse redirecionamento aqui dessa URI que o meu cliente
contém implementado né que é uma espécie de cowback E aí a minha aplicação cliente consegue Salvar esse access code e utilizá-lo nas próximas requisições então perceba que esse fluxo aqui ele é um pouco mais complicado porque tem muitas etapas mas basicamente a ideia aqui é você autenticar com as credenciais do cliente com as credenciais do usuário final que é isso aciona e gerar um autorization code intermediário para garantir que quem começou o fluxo de autorização termine Então nesse caso Olha só quantas requisições a gente tem no passo que é para obter aqui ó a primeira
tela de login a gente tem aqui Um requisição para o auto Horizon passando essas informações o cliente Direct URI essa requisição vai gerar um redirecionamento aqui ó com um autorization code depois que o usuário logar que vai ser gerado nessa location veja que a location é uma localização que existe no cliente então o cliente nesse endpoint é capaz de obter o Code o autorization Code intermediário e com ele ele vai ser capaz de fazer uma requisição autenticada aqui com as credenciais de um cliente e passando o código intermediário que foi obtido no fluxo então No
final a gente tem esse cliente autorizado com essas cores e finalmente a gente tem um fluxo implícito que também é para Spa só que ele é diferente do fluxo autorization code ele é muito parecido e o que muda é que não tem código de autorização intermediário e ele não usa o Klein Secret esse fluxo ele era usado para proteger chave o segredo do cliente quando ele está disponibilizado lá no front-link lembre-se que o front-end ele é acessível pelos clientes ele fica do lado do cliente então se você coloca as credenciais do seu cliente nele você
tá expondo elas o que a gente costumava fazer é colocar o uso também do pkce que é uma camada nova de segurança que basicamente é gerar um segredo usando uma chave privada que apenas o autorization server conhece e aí você sempre teria que passar esse segredo aqui no fluxo para garantir que você é você né garantir que você é confiável porque você conhece a chave que só o autorizam server Conhece vocês dois conhecem a palavra secreta aí para se falarem e para confirmarem as suas identidades é por causa dessas vulnerabilidade dele que a gente costuma
evitar também esse fluxo então no fundo O que que a gente vai fazer quais fluxos quais grandes a gente usa no dia a o autorization code para Spa e o clyde credentions para serviço falando com serviços Será que a gente esqueceu de algo bem se você tiver esquecido de deixar o like se inscrever no canal aproveita para fazer isso agora mas realmente a gente não falou de um detalhe A mais e uma coisinha mais aqui que é o open Nadir ou o nome completo dele o open de Connect a gente falou de um protocolo warf
que permite autorização do usuário para que ele acesse a um recurso agora a gente precisa de uma forma de identificar quem é aquela pessoa que tá autenticada Qual a identidade dele e pensando nisso é que surgiu o opening ele é focado na identidade do usuário então ele foi feito como uma extensão do off e pensando nisso ele tem algumas informações adicionais e agora ele introduz o conceito de editor é um token focado em dizer quem você é ele possui essas informações e também possui alguns padrão para você obter informações a respeito desse usuário Então você
tem o zendpoint de login para se identificar o Barra Token para obter esse editor as informações do usuário e também você é capaz de fazer login então quando a gente junto os dois ou penalide com alce a gente tem o melhor dos mundos a gente cuida da Identificação do usuário e da autorização dele de ponta a ponta nas nossas aplicações e assim como o alfine tem alguns fluxos a gente pode usar um fluxo que apenas autentica o usuário retornando o editor ou um fluxo híbrido que é o mais comum que faz autenticação e autorização retornando
os dois o egitoken e o excesso token normalmente é o que a gente usa porque a gente sempre precisa das duas coisas então a gente acaba usando sempre o opening de junto com o alfa então para resumir o off 2.0 que é a versão dele ele é um protocolo de autorização ele estabelece papéis tokens e Grant types tudo isso para autorizar o usuário a entrar no sistema nós falamos de tudo isso aqui de forma bem completa e aí para estender esse protocolo de autorização a gente também coloca o opennaid que é um protocolo de autenticação
Então a gente tem agora o editor para nos falar um pouco da identidade do usuário e temos também Ed points para fornecer essas informações Então esse foi o conteúdo aqui sobre o Alf e o open de eu trouxe esse conteúdo porque ele gera muita dúvida e é algo muito importante para a gente entender quando a gente está trabalhando com aplicações seguras então se você gostou desse conteúdo se você conseguiu entender tirar suas dúvidas curte aqui o vídeo compartilha com os colegas e se inscreve no canal para me dar essa força e eu poder trazer mais
conteúdo desse tipo para você e se você tiver interesse em aprender como usar o Spring para implementar esses protocolos comenta aqui no vídeo se vai bastante comentário eu devo trazer uma série explorando esse assunto implementação desses dois protocolos com Spring Tá ok Obrigada por assistir um abraço para você e até o próximo vídeo
