O que é autenticação baseada em token?


Respostas:


544

Eu acho que está bem explicado aqui - citando apenas as principais frases do longo artigo:

O conceito geral por trás de um sistema de autenticação baseado em token é simples. Permita que os usuários insiram seu nome de usuário e senha para obter um token que permita buscar um recurso específico - sem usar seu nome de usuário e senha. Após a obtenção do token, o usuário pode oferecer o token - que oferece acesso a um recurso específico por um período de tempo - ao site remoto.

Em outras palavras: adicione um nível de indireção para autenticação - em vez de ter que se autenticar com nome de usuário e senha para cada recurso protegido, o usuário se autentica dessa maneira uma vez (em uma sessão de duração limitada), obtém um token por tempo limitado em troca e usa esse token para autenticação adicional durante a sessão.

As vantagens são muitas - por exemplo, o usuário pode passar o token, uma vez obtido, para algum outro sistema automatizado no qual ele esteja disposto a confiar por um tempo limitado e um conjunto limitado de recursos, mas não estaria disposto confiar em seu nome de usuário e senha (ou seja, com todos os recursos que eles têm permissão para acessar, para todo o sempre ou pelo menos até que eles mudem sua senha).

Se algo ainda não estiver claro, edite sua pergunta para esclarecer o que não é 100% claro para você e tenho certeza de que podemos ajudá-lo.


6
Estou correto ao pensar que, em um aplicativo Web, um (ou mais) cookies do site remoto executa a função do token?
AJP

29
Como os tokens são armazenados como cookies, existe algo para impedir que uma pessoa roube e use esse cookie / token, fazendo com que o servidor pense que é o usuário autorizado? Obviamente, eles só poderiam usá-lo por x quantidade de tempo, mas durante esse período eles poderiam causar todo o dano necessário.
BenM

40
Como isso difere de SessionAuthentication, em que o usuário pode obter um session_id digitando seu nome de usuário e senha e, em seguida, usa esse session_id em uma solicitação subseqüente?
Saurabh Verma

4
se o token expirar, o usuário precisará fazer login novamente para obter um novo token?
Anthony To

12
@SaurabhVerma é diferente de uma sessão porque você não precisa armazenar as informações em um cookie. Isso é ótimo para dispositivos móveis, alguns dos quais têm restrições ao uso de cookies.
Kebman

182

De Auth0.com

Autenticação baseada em token, depende de um token assinado enviado ao servidor em cada solicitação.

Quais são os benefícios de usar uma abordagem baseada em token?

  • Entre domínios / CORS: cookies + CORS não funcionam bem em domínios diferentes. Uma abordagem baseada em token permite fazer chamadas AJAX para qualquer servidor, em qualquer domínio, porque você usa um cabeçalho HTTP para transmitir as informações do usuário.

  • Sem estado (também conhecido como escalabilidade no lado do servidor): não há necessidade de manter um armazenamento de sessão, o token é uma entidade independente que transmite todas as informações do usuário. O restante do estado vive em cookies ou armazenamento local no lado do cliente.

  • CDN: você pode veicular todos os ativos do seu aplicativo a partir de uma CDN (por exemplo, javascript, HTML, imagens etc.), e o servidor é apenas a API.

  • Dissociação: você não está vinculado a nenhum esquema de autenticação específico. O token pode ser gerado em qualquer lugar, portanto, sua API pode ser chamada de qualquer lugar com uma única maneira de autenticar essas chamadas.

  • Pronto para celular: quando você começa a trabalhar em uma plataforma nativa (iOS, Android, Windows 8, etc.), os cookies não são ideais quando consumir uma abordagem baseada em token simplifica muito isso.

  • CSRF: como você não depende de cookies, não precisa se proteger contra solicitações entre sites (por exemplo, não seria possível enviar seu site para outro local, gerar uma solicitação POST e reutilizar o cookie de autenticação existente, pois não haverá nenhum. )

  • Desempenho: não estamos apresentando nenhum benchmark de desempenho aqui, mas uma ida e volta da rede (por exemplo, encontrar uma sessão no banco de dados) provavelmente levará mais tempo do que calcular um HMACSHA256 para validar um token e analisar seu conteúdo.


6
@Asik Todos os pontos aqui são válidos, exceto "Stateless" quando você começa a lidar com revogação de token, lista negra, prevenção de ataques de resposta etc.
#

O site citou recomenda um artigo mais recente sobre o mesmo tema: auth0.com/blog/cookies-vs-tokens-definitive-guide
ASalazar

2
Você pode querer ler "Pare de usar JWT para sessões": cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions
Juraj Martinka

1
Asik, que tal a validade do token e quando ele expiraria? Se você adicionar essas informações, seria bom.
Arun Prakash

2
Link agora está quebrado.
Visualização elíptica

95

A tokené um dado que apenas Server Xpoderia ter sido criado e que contém dados suficientes para identificar um usuário específico.

Você pode apresentar suas informações de login e solicitar Server Xum token; e, em seguida, você pode apresentar tokene pedir Server Xpara executar alguma ação específica do usuário.

Tokens são criados usando várias combinações de várias técnicas do campo da criptografia, bem como com informações do campo mais amplo da pesquisa de segurança. Se você decidir criar seu próprio tokensistema, é melhor ser realmente inteligente.


4
Geralmente, se você deseja autenticação baseada em token, deve começar com o OAuth.
22410 Bob Aman

6
O Outh é certamente viável em um aplicativo baseado na Web. Mas, por exemplo, as sessões de login do sistema operacional também usam sistemas de token, assim como muitos outros tipos de programa de software, portanto, essa idéia não se limita à Web.
Yfeldblum 20/10/09

1
Um token também é provavelmente preferível para um sistema de suporte ao cliente não público. A empresa controla o nome de usuário / senha e emite e controla o token.
KevinManx

chrs - mas como esse sistema é diferente de um sistema baseado em sessão?
BKSpurgeon

@BKSpurgeon - Tokens são uma maneira comum de implementar sessões autenticadas.
yfeldblum 22/02

40

Um token é um dado criado pelo servidor e contém informações para identificar um usuário específico e a validade do token. O token conterá as informações do usuário, bem como um código de token especial que o usuário pode passar para o servidor com todos os métodos que suportam autenticação, em vez de passar diretamente um nome de usuário e senha.

A autenticação baseada em token é uma técnica de segurança que autentica os usuários que tentam efetuar login em um servidor, rede ou outro sistema seguro, usando um token de segurança fornecido pelo servidor.

Uma autenticação é bem-sucedida se um usuário puder provar a um servidor que ele é um usuário válido, passando um token de segurança. O serviço valida o token de segurança e processa a solicitação do usuário.

Depois que o token é validado pelo serviço, ele é usado para estabelecer o contexto de segurança para o cliente, para que o serviço possa tomar decisões de autorização ou atividade de auditoria para solicitações sucessivas do usuário.

visite a fonte


22

Baseado em token (segurança / autenticação)

significa que, para provarmos que temos acesso, primeiro precisamos receber o token. Em um cenário da vida real, o token pode ser um cartão de acesso à construção, pode ser a chave da fechadura da sua casa. Para recuperar um cartão-chave para o seu escritório ou a chave da sua casa, primeiro você precisa provar quem é e que, de fato, tem acesso a esse token. Pode ser algo tão simples quanto mostrar a alguém o seu ID ou fornecer uma senha secreta. Imagine que eu preciso ter acesso ao meu escritório. Vou até o escritório de segurança, mostro minha identidade e eles me dão esse símbolo, que me deixa entrar no prédio. Agora eu tenho acesso irrestrito para fazer o que eu quiser dentro do prédio, desde que eu tenha meu token comigo.

Qual é o benefício da segurança baseada em token?

Se pensarmos na API insegura, o que tínhamos que fazer nesse caso era que precisássemos fornecer nossa senha para tudo o que queríamos fazer.

Imagineque toda vez que entramos em uma porta de nosso escritório, precisamos fornecer a todos os que estão sentados ao lado da porta nossa senha. Agora isso seria muito ruim, porque isso significa que qualquer pessoa em nosso escritório poderia pegar nossa senha e nos representar, e isso é muito ruim. Em vez disso, o que fazemos é recuperar o token, é claro, juntamente com a senha, mas o recuperamos de uma pessoa. E então podemos usar esse token onde quisermos dentro do edifício. Obviamente, se perdermos o token, teremos o mesmo problema de alguém saber nossa senha, mas isso nos leva a coisas como garantir que, se perdermos o token, podemos revogar o acesso e talvez o token. não deve durar mais de 24 horas; portanto, no dia seguinte em que chegamos ao escritório, precisamos mostrar nossa identidade novamente. Ainda assim, há apenas uma pessoa para quem mostramos o ID,


15

A questão é antiga e a tecnologia avançou, eis o estado atual:

O JSON Web Token (JWT) é um padrão aberto baseado em JSON (RFC 7519) para transmitir declarações entre partes no ambiente de aplicativos da web. Os tokens foram projetados para serem compactos, seguros para URL e utilizáveis, especialmente no contexto de logon único (SSO) do navegador da web.

https://en.wikipedia.org/wiki/JSON_Web_Token


1
Eu não acho que o JWT represente o estado atual da tecnologia para implementar a autenticação baseada em token. É apenas uma maneira de implementá-lo e com muitas falhas que são eloquentemente colocadas por artigos como cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions
Sung Cho

3

É apenas o hash associado ao usuário no banco de dados ou de alguma outra maneira. Esse token pode ser usado para autenticar e autorizar um usuário a acessar o conteúdo relacionado ao aplicativo. Para recuperar esse token no login do lado do cliente é necessário. Após o primeiro login, você precisa salvar o token recuperado e não outros dados como sessão, ID da sessão, porque aqui tudo é token para acessar outros recursos do aplicativo.

O token é usado para garantir a autenticidade do usuário.


3

Atualmente, a abordagem mais preferida para proteger os recursos da API da Web é autenticar os usuários no servidor da API da Web usando o token assinado (que contém informações suficientes para identificar um usuário específico) que precisa ser enviado ao servidor pelo cliente com cada um e todo pedido. Isso é chamado de abordagem de autenticação baseada em token.

A autenticação baseada em token funciona da seguinte maneira:

Um usuário digita o nome e a senha no cliente (cliente significa o navegador ou dispositivos móveis etc).

O cliente envia essas credenciais (ou seja, nome de usuário e senha) ao Servidor de Autorização.

Em seguida, o servidor de autorização autentica as credenciais do cliente (ou seja, nome de usuário e senha) e, em seguida, gera e retorna um token de acesso. Este token de acesso contém informações suficientes para identificar um usuário e também o tempo de expiração do token.

O aplicativo cliente inclui o token de acesso no cabeçalho de autorização da solicitação HTTP para acessar os recursos restritos do servidor de recursos até que o token expire.

O artigo a seguir mostra como implementar a autenticação baseada em token na API WEB passo a passo.

https://dotnettutorials.net/lesson/token-based-authentication-web-api/


-2

Quando você se registra em um novo site, geralmente recebe um email para ativar sua conta. Esse e-mail normalmente contém um link para clicar. Parte desse link, contém um token, o servidor conhece esse token e pode associá-lo à sua conta. O token geralmente tem uma data de validade associada a ele; portanto, você pode ter apenas uma hora para clicar no link e ativar sua conta. Nada disso seria possível com cookies ou variáveis ​​de sessão, pois não se sabe qual dispositivo ou navegador o cliente está usando para verificar e-mails.


11
O token / link único é um conceito diferente da autenticação baseada em token.
Emile Bergeron

O nome do que você diz também é um token. Mas essa não é a questão
sajjad Yosefi 25/03
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.