Entenda a stateless session e seu uso com tokens | Alura Cursos Online
Entenda a stateless session e seu uso com tokens
6 min6 minutos de leitura
6 min6 minutos de leitura
Microservices pelo visto já é uma realidade, há inúmeros falando sobre , , arquitetura. Daqui a pouco começam falando mal ou que o está . Enfim, você provavelmente já sabe o ciclo de vida de uma BuzzWord. Voltando, eu não consigo desassociar MicroServices de um outro conceito que já foi uma buzzword há um tempo atrás. REST.
Autor(a)
lacerdaph
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Demorei anos para entender o conceito, algo que o Guilherme Silveira já falava lá em 2009 como hipermída (HATEOAS), 2010 como diminuir acoplamento, só fui compreender há pouco tempo. E um desses conceitos sempre foi para mim obscuro demais: RESTFul API, mais especificamente: ser stateless. Portanto, é esse conceito que eu vou tentar ajudar você a entender também.
Essa dúvida não é só minha: "como fugir da famosa Session em um contexto RESTFul API?". Aposto que foi um dos primeiros conceitos que você aprendeu ao lidar com programação web, que existe a possibilidade de ter um espaço alocado no servidor para cada cliente e nele você pode guardar qualquer informação relevante para o atendimento deste. Então, surge esse conceito de RESTFul API e diz que sessão na verdade não é uma boa ideia?!?!?!?! Por que isso?
vamos puxar da raiz...
Segundo Roy Fielding, ser stateless é a capacidade que um servidor tem de processar requisições de um cliente sem precisar usufruir de nenhum dado já previamente guardado nele. Logo, o envio de dados ao servidor deve conter TODA informação necessária para ser compreendida e processada. Em suma, o estado quem mantém é o cliente e não o servidor.
Agora, novamente, por que isso?
Há algumas respostas para isso, mas uma delas poderia ser quanto à escalabilidade.
imaginando o cenário...
Se o servidor cai ou aumenta o número de clientes, qual seria a solução? Ok, colocar mais um servidor e um load balancer na frente.
Agora temos um problema. O servidor 1 contém os dados do cliente, se ele cai você precisa redirecionar as requisições para o servidor 2 (ok, load balancer já faz isso). Além disso, você precisa também pegar todos os dados que estavam no servidor 1, passivá-los e transferí-los para o servidor 2. ANTES DELE CAIR!!!
Agora imagina que o seu load balancer possui um algoritmo que alterna as requisições entre servidores ao invés de fazer o stick session. A primeira é o servidor 1 que responde, a segunda é o servidor 2. E agora? A sessão do seu usuário tem que ficar trafegando entre servidores. Essa sincronia começa a ficar complicada. Logo, talvez a melhor solução, seja simplesmente evitar o problema. Aqui o peso de manter uma sessão no servidor começa a ser cobrado. O que você, eu e muuuuuuuuiiiiiiiittaaa gente acaba fazendo é simplesmente migrar o usuário para o servidor 2 sem os dados prévios. Ou seja, o usuário não "percebe" que o serviço não ficou disponível.
Perdemos aqui um item primordial, Escalabilidade horizontal. À medida que o número de clientes aumenta, são adicionados novos servidores para permitir que eles atendam à demanda crescente. E, de fato, é um pouco mais complicado de se implementar quando estamos em um arquitetura stateful.
Portanto, compreendemos o porquê de um sistema RESTFul ser totalmente stateless. As informações devem ficar no cliente e não no servidor. Por conseguinte, podemos aumentar o número de servidores e cada um será capaz de responder por novas requisições sem se preocupar em buscar dados anteriores, afinal, o cliente já vai fornecer as credenciais de quem ele é e outras informações adicionais.
frameworks podem e vão ajudar...
A resposta você provavelmente já sabe. Token! Já, inclusive, falamos sobre OAuth em um contexto MicroServices Rest. Uma outra solução seria o Json Web Token, que é um padrão aberto para representação das informações que duas partes (cliente e servidor) acordaram previamente. De fácil instalação, manipulação (fluent interface API), implementação em múltiplas linguagens (.NET, Java, Phyton) e inúmeros artigosfalando sobre o tema.
O conceito básico é: você como usuário manda sua autenticação para o servidor. Ele valida e identifica seus papéis e gera um token com essas informações para o cliente guardar. (Cookie X HTML 5 web storage). Quando requisições são feitas ao servidor, o token é enviado e as informações são recuperadas.
Para isso o token deve ser assinado com uma chave, que deve ficar no servidor. Se você precisar subir mais servidores, eles devem ter a mesma chave.
//salvando a String em um arquivo, ele poderá ser compartilhado entre servidores. String chaveAsString = Base64.getEncoder().encodeToString(MacProvider.generateKey().getEncoded());
//recuperando a chave do arquivo SecretKey chave; String nextLine = new Scanner(file).nextLine(); byte\[\] chaveEmBytes = Base64.getDecoder().decode(nextLine); chave = new SecretKeySpec(chaveEmBytes, SignatureAlgorithm.HS512.getJcaName());
Nosso famoso token...
Ao gerar o token você escolhe o conteúdo, algoritmo, tempo de expiração, dentre outros. O conteúdo precisa ser uma String, eu costumo parsear para Json.
public String gerar(Object objeto) { String objetoAsJson = new Gson().toJson(objeto); return Jwts.builder().setSubject(objetoAsJson).signWith(SignatureAlgorithm.HS512, chave).compact(); }
public <T> getConteudo(String token, Class<T> clazz) { try { String conteudo = Jwts.parser().setSigningKey(chave).parseClaimsJws(token).getBody().getSubject(); return ((T) new Gson().fromJson(conteudo, clazz)); }catch (io.jsonwebtoken.SignatureException | io.jsonwebtoken.ExpiredJwtException e) { throw new TokenInvalidoException(e); } }
E o Logoff?
O token ficará válido pelo tempo definido no setExpiration. Todavia, o usuário pode invalidar o token antes do prazo (logout). Como fazer isso? A forma mais fácil seria apenas remover o token do cliente. Se ele está guardado em um Cookie, basta remové-lo.
Mas isso não resolve o problema de alguém ainda ter guardado o token em outro lugar e usá-lo para obter informações do servidor. O que nos leva a uma segunda solução: black list de tokens. Nesse contexto, teria que existir uma lista guardada em memória(Redis, MemCached, Bolt DB), compartilhada entre os servidores, que seria consultada antes de cada requisição.
Houve essa discussão recentemente na nossa lista interna e com certeza esse é um dos pontos mais chatos, invalidar o token.
Por fim, uma outra decisão arquitetural que precisará ser discutida pela equipe é se todos os servidores vão saber descriptografar o token ou se existirá um servidor central responsável por essa abordagem. Prós e contras em ambas decisões como evitar espalhar código, ponto único de falha, requisições duplicadas (uma requisição sempre para o servidor de autenticação). E se o servidor de autenticação cair?????? E se a forma de lidar com o token precisar ser alterada??? Eu gostei bastante do JWT e achei mais fácil de lidar do que o OAuth. E você, já implementou sua API RESTFul totalmente stateless?
