Autenticação baseada em cookie x sessão x token x baseada em declarações


25

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?

Respostas:


38

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.

1
Excelente resumo! Uma coisa a ser observada ... Todos esses também são vulneráveis ​​a ataques intermediários, nos quais terceiros podem seqüestrar as informações de cookie / cabeçalho; portanto, envie todo o tráfego por HTTPS.
Brandon

3

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).
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.