Request para API com chave

[barbier]

Olá! Estava pensando nisso um dia desses sobre fazer requisições a APIs com chaves de autenticação.
Se eu deixo a minha chave no front-end, qualquer um com um mínimo de paciência pode pegá-la.
Qual seria a melhor forma de manter a chave segura? Faz sentido fazer o request no back-end e depois fornecer os dados ao front-end?

[thulioph]

Normalmente eu guardo os tokens no sessionStorage e removo ele sempre que o usuário encerra a sessão.

Já vi uma galera fazendo algo do tipo:

• se meu token é 123 eu guardo ele como 234A
• adicionando uma lógica de +1 pra cada valor e no final uma vogal

É uma maneira de burlar os curiosos, mas acredito que não seja muito útil, basta abrir o developer tools ou outra ferramenta semelhante e visualizar o que é enviado/recebido em cada request.

Vale a pena dar uma pesquisada sobre JWT pra dar um UP nesse questão de segurança e tokens.

Espero ter ajudado :)

[caioincau]

Também trabalho com o token no sessionStorage.

Teoricamente funciona bem, não deveria ser possível, através de outro dominio, ver o que está no sessionStorage.

Quanto a poder ver pelo developerTools, sim, não existe forma 100% segura de fazer isso, você pode até embaralhar com alguma criptografia de duas mãos(para evitar os mais 'noobs'), mas não é mto diferente de fazer um post com sua senha no facebook certo?

Tenho usado JWT, ele controla expiração e afins.

[danielribeirobr]

Não conheço muito a respeito de Front-End, mas a API não poderia ter um serviço que pudesse gerar uma chave dinâmica a cada autenticação, e essa chave sendo válida somente para determinado IP ou sessão?

Desculpe minha ignorância, mas sou BackendDeveloper, e não vejo problemas em armazenar dados na sessão do usuário.

[felipefialho]

@danilodevhub, pode ajudar o mano?

[nicholasess]

@barbier basicamente é assim com JWT
Quando o usuário faz login e envia os dados para a API, ela valida se o usuário existe e retorna um token com a seguinte estrutura:

jwt.encode( id do usuário, hash que descriptografa, tipo de criptografia)

Esse token será guardado via cookie que é mais seguro atualmente e melhor, por que você define qual é o dominio que será guardado e não solto.

No front end você sempre enviará via header esse token para validação de cada requisição, caso em algum momento o usuário seja barrado no sistema, não precisa ser barrado na próxima sessão, será na hora.

E para sair do sistema, basta você exclui o cookie que contém o token e redirecionar o usuário para tela de login.

[dougaraujos]

Quando você tem uma aplicação front-end consumindo recursos de API, o mínimo de segurança que você deve possuir são camadas de Autenticação e Autorização.

Agora, em questões de criptografia, eu entendo que você pode dificultar a inteligibilidade e o fluxo de obtenção dos recursos, o que refletiria apenas em filtrar quais níveis de conhecimento os usuários precisariam ter para burlar o fluxo da sua aplicação.

Vou dar um exemplo prático que estou desenvolvendo:

Tenho uma plataforma com login e tracking de vídeo, que atualiza a quantidade de tempo que o usuário visualizou o vídeo. Com a autenticação, garanto que somente aquele usuário pode modificar sua própria visualização do vídeo. Com autorização, garanto que somente aquela aplicação, a partir do token, pode atualizar os recursos através dos endpoints.

Ainda sim, ele pode inspecionar as requisições, obter o token de autorização e a identificação única do usuário e enviar requisições para atualizar o tempo de visualização quantas vezes quiser e sem necessidade de assistir ao vídeo. Ou seja, não garanto que ele vá seguir o fluxo exigido pela aplicação.

Ao atingir esse nível de necessidade de segurança, entendo que exija maior profundidade na implementação do produto, como utilização de logs e outras verificações que obriguem o fluxo ao usuário, mas foge do meu conhecimento uma alternativa a isso.

Gostaria, inclusive, de conhecer a experiência de outros devs a respeito disso.