Autenticação da Sessão vs Autenticação por Token

1. Em Session-based Authentication o Servidor faz todo o levantamento pesado do lado do servidor. Em termos gerais, um cliente autentica com as suas credenciais e recebe um session_id (que pode ser armazenado num cookie) e anexa-o a cada pedido de saída subsequente. Portanto, isto pode ser considerado um "token" pois é o equivalente a um conjunto de credenciais. No entanto, não há nada de extravagante nesta cadeia de 'session_id'. É apenas um identificador e o servidor faz tudo o resto. É stateful. Associa o identificador a uma conta de utilizador (por exemplo, na memória ou numa base de dados). Pode restringir ou limitar esta sessão a determinadas operações ou a um determinado período de tempo e pode invalidá-la se houver preocupações de segurança. Mais importante ainda, pode fazer e alterar tudo isto em tempo real. Além disso, pode registar o utilizador's cada movimento no(s) website(s). Possíveis desvantagens são a má escalabilidade (especialmente em mais do que uma exploração de servidores) e o uso extensivo da memória.

2. Em Token-based Authentication nenhuma sessão é persistida do lado do servidor (stateless). Os passos iniciais são os mesmos. As credenciais são trocadas contra um símbolo que é depois anexado a cada pedido subsequente (pode também ser armazenado num cookie). No entanto, com o objectivo de diminuir a utilização de memória, facilidade de escalabilidade e total flexibilidade (os tokens podem ser trocados com outro cliente) é emitida uma string com toda a informação necessária (o token) que é verificada após cada pedido feito pelo cliente ao servidor. Existem várias formas de utilização/criação de fichas:

3. Usando um mecanismo hash, por exemplo HMAC-SHA1

      token = user_id|expiry_date|HMAC(user_id|expiry_date, k)

   onde "user_id" e "expiry_date" são enviados em texto simples com o hash resultante anexado (o "k" só é conhecido para o servidor).

4. Encriptar o token simetricamente, por exemplo, com AES

      token = AES(user_id|expiry_date, x)

   onde x representa a chave en-/decryption.

5. Encriptando-a assimetricamente, por exemplo, com RSA

      token = RSA(user_id|expiry_date, chave privada)

**Os sistemas de produção*** são normalmente mais complexos do que estes dois arquétipos. A Amazon, por exemplo, utiliza ambos os mecanismos no seu website. Também os híbridos podem ser utilizados para emitir fichas como descrito em 2 e também associar uma sessão do utilizador a esta para rastreio do utilizador ou possível revogação e ainda manter a flexibilidade do cliente das fichas clássicas. Também o OAuth 2.0 utiliza fichas de vida curta e específica ao portador e fichas de actualização de vida mais longa, por exemplo, para obter fichas ao portador.

Fontes:

• https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
• https://stackoverflow.com/questions/1283594/securing-cookie-based-authentication
• https://web.archive.org/web/20170913233103/https://auth0.com/blog/angularjs-authentication-with-cookies-vs-token/
• https://security.stackexchange.com/questions/30707/demystifying-web-authentication-stateless-session-cookies
• https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication

O HTTP é sem estado, e para ter um estado autenticado, é necessário algum tipo de ficha utilizada para referenciar informação sobre o utilizador. Esta identificação de sessão é geralmente na forma de um símbolo aleatório enviado como um valor de cookie. Um OAuth Token de Acesso é utilizado para identificar um utilizador, e o 'âmbito' dos recursos a que o utilizador tem acesso. Em aplicações que utilizam um único sinal OAuth, um token de Acesso OAuth é normalmente trocado por um identificador de sessão que pode acompanhar uma maior variedade de estados do utilizador.

Da perspectiva de um atacante's, sequestrar uma identificação de sessão, ou OAuth Access Token, é tão bom como um nome de utilizador e senha, e por vezes é ainda melhor. Os IDs de sessão devem ter propriedades de segurança que protegem as contas dos utilizadores de compromissos.

Da perspectiva do programador's, **nunca reinvente a roda***. Utilize o gestor de sessão fornecido pela sua plataforma, e assegure-se de que está configurado de acordo com as directrizes de Gestão de Sessão OWASP.

Assim, sobre a autenticação baseada na sessão, para aumentar a segurança no acesso aos recursos que é necessário:

• Deve ser usado como um substituto para uma credencial de utilizador's
• Deve usar sempre um cookie persistente
• Deve identificar os utilizadores que regressam ao website
• Deve usar autenticação de 2 factores