API RESTful com tokens de sessão .. ehh?

5

Depois de olhar para muitos debates de sessão / estado com relação ao REST e não encontrar nada concreto, eu vou direto ao assunto e me pergunto.

Desenvolvendo uma API RESTful como back-end para um aplicativo móvel, eu (acho que) quero acompanhar todos os usuários (mesmo os não registrados) com as sessões guest . Isso permite que eu personalize o conteúdo e faça estatísticas sobre meus usuários.

Em termos de implementação, eu gostaria que meu aplicativo se identificasse, como se fosse um terminal / autenticado, sem e-mail / senha, mais como UUID. Mas isso efetivamente faz com que toda a API espere um "token de sessão" com cada solicitação.

Esta é uma abordagem ruim, ou você faria o mesmo?

    
por Zoon 09.01.2017 / 17:21
fonte

2 respostas

5

A abordagem usual é simplesmente fornecer um token de sessão ao cliente por meio de cabeçalhos ou cookies, caso eles não forneçam um ou forneçam um inválido. Isso é especialmente necessário para clientes da Web em que a sessão pode expirar enquanto eles estão em uma página em algum lugar. Isso garante que você tenha sua sessão imediatamente, sem ir ao ponto final "autenticar", que deve fazer o que seu nome sugere: autenticar o usuário.

Naturalmente, isso significa que o cliente deve ser projetado para esperar que o token de sessão seja alterado, mas isso é uma coisa boa . Regenerar o token de sessão, particularmente em alterações de privilégio (ou seja, ir de convidado para usuário completo), ajuda a evitar o seqüestro de sessão. E não pense que só porque você é um aplicativo móvel em vez de uma página da Web, você está protegido contra seqüestros. Você não é, um hacker pode usar o Fiddler ou algum outro proxy para interceptar sua API móvel.

    
por 09.01.2017 / 18:40
fonte
-1

Por que essa abordagem não parece ser uma boa ideia?

  1. Motivos de segurança: criar seu próprio "token de sessão" é um grande risco de vulnerabilidade. Um exemplo que me vem à mente aqui é o sequestro de tokens (por exemplo, no dispositivo, mesmo se o canal de comunicação fosse protegido por TLS).

  2. De qualquer forma, conceitualmente, isso não se encaixa na arquitetura: seu token conterá um número exclusivo que você precisa acompanhar ao lado do serviço. Isso significa que o serviço tem um estado (por exemplo, UUID ativo). Mas na sua pergunta você quer o serviço RESTful , que significa apátrida.

  3. Como alternativa, você pode evitar o estado no servidor armazenando-o no token (isto é, o UUID, uma informação adicional que combina com o UUID permite avaliar se o UUID é válido e o ID do usuário). Mas então, você se expõe à falsificação de seu token (por exemplo, login para obter um UUID + adequado e, em seguida, sobrescreve o ID do usuário com um id com mais privilégios).

Melhor alternativa

Para evitar a implementação de um conjunto de vulnerabilidades, use somente protocolos padronizados comprovados. Por exemplo, em vez de reinventar seu próprio token, use o comprovado JWT que é protegido criptograficamente.

Leitura adicional:

por 09.01.2017 / 19:15
fonte