Eu li sobre autenticações e fiquei confuso sobre a classificação de tipos.

Vamos começar pela autenticação baseada em cookies. Se eu entendi direito, o ponto principal é que todos os dados, necessários para a autenticação do usuário, são armazenados em cookies. E esta é minha primeira confusão: em cookies, podemos armazenar

• identificação da sessão e, assim, torna-se uma autenticação baseada em sessão?
• reivindicações e, portanto, deve ser chamada como autenticação baseada em declarações?
• Descobri que algumas pessoas até armazenam token JWT em cookies, mas isso parece uma implementação personalizada do próprio fluxo de autenticação ...

Agora vamos mudar para autenticação baseada em declarações. O elemento principal é a declaração e a coleção de declarações pode ser usada como contêiner

• cookies (como discutido acima)
• token (JWT como o exemplo).

Por outro lado, quando estamos falando sobre o token, ele pode conter qualquer tipo de informação ... ID da sessão, por exemplo ...

Então o que eu perdi? Por que as pessoas não definem algo como Cookie-Session-basedou Token-Claims-basedautenticações ao falar sobre tipos de autenticação?

Concordo que a nomeação dos diferentes conceitos é confusa. Ao falar sobre autenticação em um contexto da web, há vários aspectos a serem considerados.

Quais informações o cliente envia ao autenticar?

• Um ID de sessão . Isso significa que o servidor possui um armazenamento de sessão que contém as sessões ativas. As sessões são monitoradas com estado no lado do servidor.
• Um conjunto de reivindicações . As declarações contêm informações sobre quais operações o cliente pode executar. O servidor não controla cada cliente autenticado, mas confia nas reivindicações. As declarações normalmente não têm estado no lado do servidor.

Como o cliente envia as informações de autenticação?

• Cookies . Os navegadores enviam cookies automaticamente a cada solicitação, após a configuração do cookie. Os cookies são vulneráveis ​​ao XSRF.
• Outros cabeçalhos . Normalmente, o cabeçalho de autorização é usado para isso. Esses cabeçalhos não são enviados pelo navegador automaticamente, mas precisam ser definidos pelo cliente. Isso é vulnerável ao XSS.
• URL de solicitação . As informações de autenticação estão incluídas no URL. Isso não é comumente usado.

Qual é o formato das informações de autenticação?

• Texto simples e não assinado . Isso pode ser usado para identificações de sessão. Uma identificação de sessão geralmente não pode ser adivinhada pelo cliente; portanto, o servidor pode confiar que o cliente não a forjou.
• Json Web Token . As JWTs são assinadas criptograficamente e contêm informações de validade. O cliente geralmente pode decodificar o token, mas não pode alterá-lo sem que o servidor perceba.
• Qualquer outro formato assinado . O mesmo que JWTs. O importante é a assinatura criptográfica, que impede o cliente de alterar os dados.

Bônus: como o cliente armazena as informações localmente

• Cookies . É claro que esse é o caso ao usar cookies para transmitir as informações. Mas os cookies também podem ser usados ​​apenas como um mecanismo de armazenamento do lado do cliente. Isso requer que o cookie seja legível dos scripts para ser útil. Por exemplo, um cliente pode ler o cookie com JavaScript e enviar as informações com um cabeçalho de autorização.
• Armazenamento local . Geralmente, esse é o único método possível, se os cookies não estiverem disponíveis. Requer gerenciamento com JavaScript.

O que as pessoas querem dizer quando dizem ...

• "Autenticação baseada em cookie" . Acho que isso geralmente significa "ID da sessão, enviado por cookie, possível como texto sem formatação".
• "Autenticação baseada em token" . Normalmente, isso significa "Reivindicações, envie usando o cabeçalho de autenticação, codificado como um Json Web Token".
• "Autenticação baseada em declarações" . Pode ser qualquer coisa, menos um ID de sessão.

Simplificando,

1. Autenticação baseada em cookie

   • O cliente da Web (por exemplo: navegador da Web) armazena o cookie enviado pelo servidor da Web após a autenticação bem-sucedida.
   • O cookie contém informações sobre o usuário, cliente, carimbo de data / hora authN e outros dados úteis com o ID exclusivo para determinar o cookie.
   • Normalmente, o cookie é criptografado pelo servidor da web com o atributo de domínio definido (por exemplo google.com:) e o envia para o cliente da web.
   • Sempre que o cliente da Web desejar acessar o recurso do domínio (por exemplo mail.google.com:), ele enviará todos os cookies com base em seu domínio (por exemplo google.com:) para o servidor da Web, que valida / verifica e concede / nega acesso com base no estado e no carimbo de data / hora de o biscoito.

2. Autenticação baseada em sessão

   • Juntamente com o cookie do cliente da Web, se um servidor da Web armazenar os dados de authN do usuário em seu back-end, ele será chamado de autenticação baseada em sessão.
   • Isso é muito útil no caso de qualquer violação que o cliente da Web tenha acesso ao sistema onde não deve ter acesso; em seguida, a partir do back-end, a sessão do cliente da Web pode ser revogada pelo administrador.

3. Autenticação baseada em token

   • Geralmente, isso é usado em cenários que não são de clientes da Web, nos quais não há como armazenar cookies no lado do cliente.
   • Portanto, o servidor da Web envia o token assinado (contém informações sobre usuário, cliente, carimbo de data / hora authN e outros dados úteis com identificação exclusiva) ao cliente após a autenticação bem-sucedida.
   • Sempre que um cliente deseja acessar um recurso, ele precisa enviar esse token e o servidor da Web valida / verifica o token antes de permitir o acesso ao recurso.

4. Autenticação baseada em declarações

   • É o mesmo que autenticação baseada em token, apenas que ela adiciona mais alguns dados ao token sobre o cliente e / ou usuário associado ao cliente.
   • Esses dados são referentes à autorização, que fala sobre o que o cliente deve fazer no recurso (por exemplo: mail.read, mail.delete, calendar.read).