Autenticação do usuário do servidor REST

5

Então, estou criando meu primeiro aplicativo de escala maior (por escala maior, quero dizer algo que eu vejo publicando na loja de aplicativos) e não tenho certeza de como lidar com a autorização do usuário. O cliente consistirá de um aplicativo para android e iphone, e eles fazem solicitações HTTP em um servidor.

Meus dados são armazenados em um servidor postgreSQL e eu já implementei para que um usuário possa fazer o login, mas agora, logar basicamente não significa nada. Quando você consulta o banco de dados, não há verificação para garantir que os dados solicitados / desejados sejam alterados.

Eu estava pensando que, quando um usuário faz login, recebe um token. Sempre que uma solicitação for feita com um ID de usuário, o host que solicita esses dados também deve fornecer esse token de IDs.

As consultas são feitas com chamadas de descanso e geralmente têm a forma [id de usuário, novos dados 1, novos dados 2, novos dados 3], e esses novos dados serão inseridos em uma tabela, e a nova linha será ter uma relação com o ID do cliente.

Os dados que eu armazeno não são sensíveis. A maioria das solicitações será um usuário que deseja adicionar uma linha a uma tabela no meu banco de dados. A parte mais sensível provavelmente seria um e-mail de usuários, portanto, esse sistema de autenticação só seria implementado para garantir que ninguém esteja inserindo dados de trolls em um cliente que não seja eles.

Outro ponto que não sei como lidar é o que fazer quando o token expirar. Não consigo solicitar que o usuário efetue login em intervalos de algumas horas, o token deve ser renovado automaticamente. É normal armazenar id / pass no cliente e fazer o pedido automaticamente?

    
por Rewbert 01.06.2016 / 21:17
fonte

2 respostas

2
Primeiro, a abordagem do token parece ser adequada para o seu caso. Uma opção é criptografar as informações do usuário (por exemplo, id) no token. No lado do servidor, você pode manter as coisas sem estado. Perceba que não importa os detalhes de como ele é gerado, esse token é sensível. Se alguém o tiver, ele poderá usá-lo para fingir ser esse usuário, desde que seja válido (assim como um id de sessão).

Para a última parte, não está claro qual é o requisito de login aqui. Você diz que não quer que eles tenham que fazer login a cada poucas horas. Com que frequência você deseja que eles façam logon e isso é baseado em inatividade? Eu não recomendaria armazenar as credenciais, pois outros aplicativos no dispositivo poderiam recuperar as credenciais.

    
por 02.06.2016 / 18:15
fonte
1

Não sei realmente o caso de uso completo, mas isso realmente grita usando uma sessão para mim. Normalmente, eles são implementados com um ID exclusivo enviado ao cliente na forma de um cookie e armazenado no servidor em um banco de dados de memória como redis ou memcached .

Quando um usuário registra um novo objeto será adicionado a redis e armazenado por uma chave exclusiva com qualquer informação de usuário necessária, um tempo de expiração também pode ser definido aqui. Definir uma expiração removerá automaticamente uma chave do cache, o que tornará a sessão do usuário inválida se ela ultrapassar a data de expiração. Para o seu caso, ele provavelmente armazenaria apenas o ID do usuário, ele também poderia ser usado para armazenar quaisquer dados estáticos comumente usados que não precisem ser consultados todas as vezes.

Como as informações da sessão são úteis na maioria dos endpoints, um filtro de nível superior é normalmente implementado para consultar redis da chave e armazenar as informações do usuário na solicitação antes que qualquer handler logic seja executada. Se a chave não existir, um 403 status poderia ser enviado na resposta.

Tudo depende da tecnologia do lado do servidor que você está usando, mas esse padrão é muito comum e já pode ser implementado na estrutura que você está usando. Por exemplo, eu escrevi alguns códigos pseudoish em poucos minutos que usa express e seu objeto redis session. Apenas com algumas linhas de código, ele fornece suporte de expiração de sessão e segurança de dados do usuário.

    var session = require('express-session');
var RedisStore = require('connect-redis')(session);

//this is middleware provided by the library which will query 'redis'
// from the request cookie, add the session to the request data and
//update the expiry with user activity.
app.use(session({
    store: new RedisStore({ttl: 10000000}),
    secret: 'keyboard cat'
}));

app.post('login', function(req, resp) {
    var sessionData = doLogin(req);
    //store the session data on the request if login is successful
    if(sessionData) {
        req.session = sessionData;
    }

    resp.send(200);
});

app.post('insert', function(req, resp) {
     var userId = req.session && req.session.userId;
     // use the session data to validate the user
     if(userId) {
        doInsert(req);
        resp.send(200);
     }
     else {
        resp.send(403);
     }
}); 

Apenas uma nota secundária, normalmente uma API não deve levar o usuário como um parâmetro para manipular dados para um usuário porque é muito propenso a hackers. Armazenar as informações do usuário em uma sessão e sempre referenciar as informações do usuário evitará qualquer manipulação não autorizada de dados do usuário.

    
por 02.06.2016 / 17:12
fonte