Me corrijam se eu estiver errado, mas durante a aula aprendemos que a utilização de SESSÃO é importante, uma vez que o processo REQUEST-RESPONSE do HTTP é STATELESS. Pelo o que entendi, a sessão automatiza essa relação, evitando que usuário fique preenchendo/repetindo informações já fornecidas a cada sessão. O uso de cookies é um meio para criarmos a sessão. Até aí tudo bem.

Porém, lendo um material publicado aqui no fórum, relacionado ao método REST, é explicado que o uso da SESSÃO não torna totalmente STATELESS nosso serviço REST. É orientado que a aplicação utilize TOKENS DE ACESSO para otimizar as requisições. Pelo o que entendi, isso minimiza a necessidade de armazenamento dentro do servidor, mitigando custos, presumo.

Enfim, poderiam explicar melhor essa relação?

E aí Roger! Vou explicar a você um pouco mais sobre essa relação de TOKENS, COOKIES e SESSÕES. São coisas muito próximas e que podem causar certa confusão na hora de implementá-las.

Uma pequena relação lógica

TOKENS e SESSIONS podem ser COOKIES; SESSIONS podem usar TOKENS; SESSIONS podem usar IDs, quando usam são salvos em COOKIES;

Explicando de fato

Tokens e IDs são usados para a autenticação de um usuário. A autenticação é necessária para prover maior privacidade de certos dados (ex: mensagens, conteúdos pagos, etc.). Como a relação entre servidor e cliente é stateless o servidor pode solucionar isso de 2 formas: IDs ou TOKENS.

IDs

Os IDs são stateful. O usuário preenche suas credenciais em uma página (como usuário e senha), o servidor autentica ele e, se for válido, envia um ID que é salvo nos cookies do cliente. Dessa forma, em novas requisições não será necessário o preenchimento de suas credenciais novamente. Pois cookies são enviados junto nas requisições. De modo simplificado: 1 O usuário insere suas credenciais de login. 2 O servidor verifica se as credenciais estão corretas e cria uma sessão que é armazenada em um banco de dados. 3 Um cookie com o ID da sessão é colocado no navegador do usuário. 4 Em solicitações subsequentes, a ID da sessão é verificada no banco de dados e se a solicitação processada é válida. 5 Depois que um usuário se desconecta do aplicativo, a sessão é destruída tanto no lado do cliente quanto no lado do servidor.

TOKENS

Agora chegamos em um ponto mais delicado que eu sugiro que para um maior entendimento você faça uma profunda busca no maravilhoso mundo da internet! O tipo de token mais difundido na internet atualmente é o JWT. Então discorrerei a seguir sobre a sua utilização. Para começar, saiba que a autenticação baseada em token não tem estado. O servidor não mantém um registro de quais usuários estão conectados ou quais JWTs foram emitidos! Em vez disso, cada solicitação ao servidor é acompanhada por um token que o servidor usa para verificar a autenticidade da solicitação. O token é geralmente enviado como um cabeçalho de Autorização adicional, mas também é comum que sejá enviado dentro do corpo de uma solicitação tipo POST ou até como um parâmetro de consulta (GET). De modo simplificado: 1 O usuário insere suas credenciais de login. 2 O servidor verifica se as credenciais estão corretas e retorna um token assinado. 3 Esse token é armazenado no lado do cliente, mais comumente no armazenamento local - mas pode ser armazenado no armazenamento da sessão ou também em um cookie. 4 As solicitações subsequentes ao servidor incluem esse token como um cabeçalho de autorização adicional ou por meio de um dos outros métodos mencionados acima. 5 O servidor decodifica o JWT e, se o token for válido, processa a solicitação. 6 Depois que um usuário efetua logout, o token é destruído do lado do cliente, nenhuma interação com o servidor é necessária.

Conclusão

TOKENS e IDs (ou cookies como é apresentado em alguns fóruns) são importantes componentes na hora de "driblar" o stateless do http e evitar múltiplas autenticações de usuário. Tokens tendem a ser mais seguros, mais pesados, melhor empregados para iOs e Android e com mais eficiência no âmbito do IoT. Espero ter lhe ajudado com sua dúvida.