Pergunta

O que Autenticação RESTful significa e como ele funciona? Não consigo encontrar uma boa visão geral no Google. Meu único entendimento é que você passa a chave de sessão (remeberal) na URL, mas isso poderia ser terrivelmente errado.

Foi útil?

Solução

Como lidar com a autenticação em uma arquitetura RESTful cliente-servidor é uma questão de debate.

Normalmente, ele pode ser alcançado, na SOA sobre o mundo HTTP via:

  • HTTP básico auth sobre HTTPS;
  • Biscoitos e gerenciamento de sessão;
  • token nos cabeçalhos de HTTP (por exemplo, OAuth 2,0 + JWT);
  • Autenticação consulta com parâmetros de assinatura adicionais.

Você vai ter que se adaptar, ou melhor ainda misturar essas técnicas, para corresponder à sua arquitetura de software na melhor das hipóteses.

Cada esquema de autenticação tem suas próprias vantagens e desvantagens, dependendo do propósito da sua política de segurança e arquitetura de software.

HTTP básico auth sobre HTTPS

Esta primeira solução, baseada no protocolo HTTPS padrão, é usado pela maioria dos serviços web. 

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

É fácil de implementar, disponível por padrão em todos os navegadores, mas tem alguns inconvenientes conhecidos, como a janela de autenticação terrível exibido no navegador, que irá persistir (não há LogOut-como característica aqui), alguns do lado do servidor adicional consumo de CPU, eo fato de que o nome de usuário ea senha são transmitidos (HTTPS) para o Server (que deve ser mais seguro para deixar a estadia senha somente no lado do cliente, durante a entrada de teclado, e ser armazenados como Hash seguro em o Server).

Podemos usar Digest Authentication , mas requer também HTTPS, já que é vulnerável a < a href = "http://en.wikipedia.org/wiki/Man-in-the-middle_attack" rel = "noreferrer"> MiM ou ataques de repetição , e é específico para HTTP.

Session via cookies

Para ser honesto, uma sessão gerenciado no servidor não é verdadeiramente Stateless.

Uma possibilidade poderia ser a de manter todos os dados dentro do conteúdo cookie. E, pelo projeto, o cookie é tratado no lado do servidor (cliente, de fato, sequer não tentar interpretar esses dados de cookies: só as mãos de volta para o servidor em cada solicitação sucessiva). Mas esses dados cookies são dados estado do aplicativo, de modo que o cliente deve geri-lo, não o servidor, em um mundo puro Stateless. 

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

A técnica de cookie em si é HTTP ligada, por isso não é realmente RESTful, que deve ser independente de protocolo, IMHO. Ele é vulnerável a MiM ou Repetição ataques.

Concedido via token (OAuth2)

Uma alternativa é colocar um símbolo dentro do cabeçalhos HTTP para que o pedido seja autenticado. Isto é o que OAuth 2.0 faz, por exemplo. Consulte o RFC 6749 : 

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

Em suma, este é muito semelhante a um cookie e sofre com os mesmos problemas: não apátrida, contando com HTTP detalhes da transmissão, e sujeito a um monte de falhas de segurança - incluindo MIM e de repetição - assim é para ser usado apenas por HTTPS. Tipicamente, uma JWT é utilizado como um sinal.

Autenticação de consulta

Autenticação de consulta consiste na assinatura de cada pedido RESTful via alguns parâmetros adicionais na URI. Consulte este artigo referência .

Foi definido como tal neste artigo:

Todas as consultas de descanso devem ser autenticados pela assinatura dos parâmetros de consulta classificadas em letras minúsculas, ordem alfabética usando a credencial privada como o token de assinatura. Assinando deve ocorrer antes de URL que codifica a query string.

Esta técnica ié talvez o mais compatível com uma arquitetura sem estado, e também pode ser implementado com um gerenciamento de sessões de luz (utilizando sessões na memória em vez de DB persistência).

Por exemplo, aqui está uma amostra URI genérico a partir do link acima: 

GET /object?apiKey=Qwerty2010

devem ser transmitidos como tal: 

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

A string a ser assinado é /object?apikey=Qwerty2010&timestamp=1261496500 ea assinatura é o hash SHA256 dessa string usando o componente privada da chave API.

cache de dados do lado do servidor pode estar sempre disponível. Por exemplo, em nossa estrutura, podemos armazenar em cache as respostas ao nível do SQL, não no nível URI. Assim, adicionando este parâmetro extra não quebrar o mecanismo de cache.

este artigo para alguns detalhes sobre a autenticação RESTful no nosso quadro ORM / SOA / MVC cliente-servidor, com base em JSON e REST. Uma vez que permitem a comunicação não só através de HTTP / 1.1, mas tubos também nomeados ou mensagens GDI (localmente), tentamos implementar um padrão de autenticação verdadeiramente RESTful, e não depender de HTTP especificidade (como cabeçalho ou cookies).

Mais tarde Nota : adicionando uma assinatura na URI pode ser visto como má prática (uma vez que, por exemplo, ele aparecerá nos logs do servidor http), por isso tem de ser mitigada, por exemplo, por um TTL adequada para evitar repetições. Mas se os seus registos de HTTP estão comprometidos, você certamente vai ter problemas de segurança maiores.

Na prática, o próximo MAC tokens de autenticação para OAuth 2.0 pode ser uma grande melhoria em relação ao "Concedido pelo token" esquema atual. Mas isso ainda é um trabalho em andamento e está ligada ao HTTP transmissão.

Conclusão

Vale a pena concluindo que o descanso não é apenas baseado em HTTP, mesmo que, na prática, também é principalmente implementada através de HTTP. DESCANSO pode utilizar outras camadas de comunicação. Assim, uma autenticação RESTful não é apenas sinônimo de HTTP autenticação, sejam quais forem as respostas do Google. Ele ainda não deve usar o mecanismo HTTP em todos, mas será captada a partir da camada de comunicação. E se você usar HTTP comunicação, graças ao Vamos iniciativa Criptografar não há nenhuma razão para não usar adequada HTTPS, que é necessário para além de qualquer esquema de autenticação.

Outras dicas

duvido que as pessoas com entusiasmo gritando "HTTP Autenticação" já tentou fazer um aplicativo baseado em navegador (em vez de um serviço web machine-to-machine) com repouso (sem querer ofender - Eu só não acho que eles já enfrentou as complicações).

Os problemas que eu encontrei com o uso de HTTP autenticação em serviços RESTful que as páginas de produtos HTML para ser visualizados em um navegador são:

  • usuário normalmente recebe uma caixa de login fez-browser feio, que é muito user-hostil. você não pode adicionar recuperação de senha, caixas de ajuda, etcetera.
  • fazer logoff ou efetuar login com um nome diferente é um problema - navegadores irá manter o envio de informações de autenticação para o site até que você feche a janela
  • tempos de espera são difíceis

Um artigo muito perspicaz que aborda estas ponto por ponto é aqui , mas isso resulta em um muito de hackery javascript específicas do navegador, soluções alternativas para soluções alternativas, et cetera. Como tal, também não é para a frente compatível assim vai exigir manutenção constante à medida que novos navegadores são liberados. Eu não considero que o design limpo e claro, mais eu sinto que é um monte de trabalho extra e dor de cabeça apenas para que eu possa entusiasticamente mostrar o meu REST crachá para os meus amigos.

Eu acredito que os cookies são a solução. Mas espere, os cookies são maus, não são? Não, eles não estão, a forma como os cookies são frequentemente utilizados é mau. Um cookie em si é apenas um pedaço de informação do lado do cliente, assim como a informação de autenticação HTTP que o navegador iria acompanhar enquanto você navega. E este pedaço de informação do lado do cliente é enviado para o servidor em cada solicitação, novamente como o HTTP informações de autenticação seria. Conceitualmente, a única diferença é que o conteúdo deste pedaço de estado do lado do cliente pode ser determinado pelo servidor , como parte de sua resposta.

Ao fazer sessões de um recurso RESTful apenas com as seguintes regras:

  • A sessão mapeia uma chave para uma identificação de usuário (e possivelmente a última ação timestamp para timeouts)
  • Se um sessão existe, então isso significa que a chave é válido.
  • Entrar significa postagem para / sessões, uma nova chave é definida como um cookie
  • Sair significa deleteing / sessões / {key} (com o POST sobrecarregado, lembre-se, estamos um navegador e HTML 5 é um longo caminho a percorrer até o momento)
  • A autenticação é feita enviando a chave como um cookie em cada solicitação e verificar se a sessão existe e é válido

A única diferença para autenticação HTTP, agora, é que a chave de autenticação é gerado pelo servidor e enviado para o cliente que continua a enviá-lo, em vez do cliente de computação la das credenciais inseridas.

converter42 acrescenta que, ao usar https (que deveria), é importante que o cookie terá o seu conjunto de sinalizador seguro para que informações de autenticação nunca é enviado através de uma conexão não segura. Grande ponto, não tinha visto isso sozinho.

Eu sinto que esta é uma solução suficiente de que funciona bem, mas devo admitir que eu não sou o suficiente de um especialista em segurança para identificar falhas potenciais neste esquema - Tudo o que sei é que centenas de aplicações web não RESTful usar essencialmente o mesmo protocolo de início de sessão ($ _ Session em PHP, HttpSession em Java EE, etc). O conteúdo de cabeçalho de cookie são simplesmente usados ??para tratar um recurso do lado do servidor, apenas como um accept-language pode ser usado para recursos de tradução de acesso, etcetera. Eu sinto que é o mesmo, mas talvez outros não? O que você acha, rapazes?

Bastante já é dito sobre este tema por boas pessoas aqui. Mas aqui é o meu 2 centavos.

Existem 2 modos de interação:

  1. homem-a-máquina (HTM)
  2. máquina-para-máquina (MTM)

A máquina é o denominador comum, expressa como a API repouso, e os actores / clientes sendo tanto os seres humanos ou as máquinas.

Agora, em uma arquitetura verdadeiramente RESTful, o conceito de apatridia implica que todos os estados da aplicação relevantes (ou seja, os estados lado do cliente) deve ser fornecida com cada pedido. Por relevante, entende-se que tudo o que é exigido pela API REST para processar o pedido e servir uma resposta apropriada.

Quando consideramos isso no contexto de aplicações humano-máquina "navegador baseado em" como Skrebbel aponta acima, isso significa que o aplicativo (web) em execução no navegador precisará enviar suas informações de estado e relevante com cada pedido faz-se à API REST do back-end.

Considere o seguinte: Você tem uma plataforma de dados / informações sobre os ativos expostos de APIs REST. Talvez você tenha um self-service plataforma de BI que lida com todos os cubos de dados. Mas você quer que seus clientes (humanos) para acessar a via aplicativo (1) aplicação web, (2) móvel, e (3) alguns 3ª aplicação festa. No final, mesmo cadeia de MTMs leva até HTM - direita. Assim, os usuários humanos permanecem no ápice da cadeia de informação.

Nos primeiros 2 casos, você tem um caso para a interação homem-a-máquina, a informação a ser efetivamente consumido por um usuário humano. No último caso, você tem um programa de máquina de consumir as APIs REST.

O conceito de autenticação se aplica em toda a linha. Como você vai projetar isso para que suas APIs REST são acessados ??de uma maneira uniforme e segura? A forma como eu vejo isso, existem 2 formas:

Way-1:

  1. Não há login, para começar. Cada pedido executa o login
  2. O cliente envia seus parâmetros de identificação + o pedido específico parâmetros com cada pedido
  3. A API REST leva-los, se vira, pings armazenamento do usuário (Qualquer que seja) e confirma a auth
  4. Se a autenticação é estabelecida, os serviços do pedido; caso contrário, nega com código de status HTTP apropriado
  5. Repita os passos acima para cada pedido em todas as APIs REST em seu Catálogo

Way-2:

  1. O cliente começa com um pedido de auth
  2. Um login API REST irá lidar com todos esses pedidos
  3. É preciso nos parâmetros de autenticação (chave de API, uid / pwd ou o que você escolher) e verifica auth contra o armazenamento do usuário (LDAP, AD, ou MySQL DB etc.)
  4. Se verificada, cria uma auth token e as mãos de volta para o cliente / chamador
  5. O chamador, em seguida, envia esta auth token de + params pedido específico com cada solicitação subseqüente a outras APIs de REST negócio, até desconectado ou até o contrato expirar

Claramente, Way-2, as APIs resto vai precisar de uma maneira de reconhecer e confiar o token como válido. O Acesso de API realizada a verificação auth, e, portanto, que as necessidades "chave valet" para ser confiável por outras APIs REST em seu catálogo.

Isto, naturalmente, significa que o / necessidade vontade chave auth token a ser armazenados e compartilhados entre os APIs REST. Este compartilhada, confiável repositório token pode ser local / federada que seja, permitindo APIs descansar de outras organizações para confiar um no outro.

Mas eu discordo.

O ponto é, um "estado" (sobre o estado autenticada do cliente) precisa ser mantida e compartilhada para que todas as APIs resto pode criar um círculo de confiança. Se não fizermos isso, que é o Caminho-1, temos de aceitar que um ato de autenticação deve ser realizada para qualquer / todos os pedidos que chegam.

Performing autenticação é um processo intensivo de recursos. Imagine que a execução de consultas SQL, para cada solicitação de entrada, contra o seu armazenamento do usuário para verificar se há uid / pwd jogo. Ou, para criptografar e executar jogos de hash (o estilo AWS). e architecturally, cada API REST vai precisar para realizar isso, eu suspeito, usando um serviço comum de login back-end. Porque, se você não fizer isso, então você lixo do código de autenticação em todos os lugares. Uma grande bagunça.

Assim, mais as camadas, mais latência.

Agora, pegue Way-1 e se aplicam a HTM. Será que o seu utilizador (humano) realmente se importa se você tem que enviar uid / pwd / hash ou o que quer com cada pedido? Não, desde que você não incomodá-la, atirando a página auth / login a cada segundo. Boa sorte ter clientes se o fizer. Então, o que você vai fazer é armazenar a algum lugar informações de login no lado do cliente, no navegador, logo no início, e enviá-lo com cada pedido feito. Para o usuário (humano), ela já logado, e uma "sessão" está disponível. Mas, na realidade, ela é autenticado em cada solicitação.

Mesmo com Way-2. Seu usuário (humano) nunca vai notar. Portanto, nenhum dano foi feito.

O que se aplicarmos Way-1 a MTM? Neste caso, desde a sua uma máquina, podemos suportou o inferno fora desse cara, pedindo que enviar informações de autenticação com cada pedido. Ninguém se importa! Realizando Way-2 no MTM não evocam nenhuma reação especial; a sua máquina a mínima. Ele poderia me importar menos!

Então, realmente, a questão é o que se adapte às suas necessidades. Apatridia tem um preço a pagar. Pagar o preço e seguir em frente. Se você quer ser um purista, em seguida, pagar o preço por isso também, e seguir em frente.

No final, filosofias, não importa. O que realmente importa é a descoberta de informações, apresentação, ea experiência de consumo. Se as pessoas adoram suas APIs, você fez o seu trabalho.

Aqui está uma solução de autenticação verdadeiramente e completamente RESTful:

  1. Criar um par de chaves pública / privada no servidor de autenticação.
  2. Distribuir a chave pública para todos os servidores.

  3. Quando um cliente autentica:

    3.1. emitir um sinal que contém o seguinte:

    • tempo de expiração
    • Nome usuários (opcional)
    • usuários IP (opcional)
    • de hash de uma senha (opcional)

    3.2. Criptografar o token com a chave privada.

    3.3. Enviar a volta token criptografado para o usuário.

  4. Quando o usuário acessa qualquer API eles devem também passar em seu token de autenticação.

  5. Os servidores podem verificar se o token é válido, decifrando-lo usando a chave pública do servidor de autenticação.

Esta é apátrida / autenticação RESTful.

Note que, se um hash de senha foram incluídos o usuário também enviar a senha não criptografada, juntamente com o token de autenticação. O servidor pode verificar se a senha combinava com a senha que foi usada para criar o token de autenticação comparando hashes. Uma conexão segura usando algo como HTTPS seria necessário. Javascript no lado do cliente poderia lidar com ficando a senha do usuário e armazená-lo do lado do cliente, seja na memória ou em um cookie, possivelmente criptografada com pública do servidor chave.

Para ser honesto com você eu tenho visto grandes respostas aqui, mas algo que me incomoda um pouco é quando alguém vai levar todo o conceito Stateless a um extremo onde se torna dogmático. Isso me lembra os velhos fãs Smalltalk que só queria abraçar OO pura e se algo não é um objeto, então você está fazendo errado. Dá um tempo.

A abordagem RESTful é suposto para tornar sua vida mais fácil e reduzir a sobrecarga e os custos de sessões, tentar segui-lo, pois é uma coisa sensata a fazer, mas o minuto que você siga uma disciplina (qualquer disciplina / orientação) para o extrema em que já não fornece o benefício que se destina, então você está fazendo errado. Algumas das melhores linguagens de hoje têm ambos, funcional orientação de programação e objeto.

Se a maneira mais fácil para você resolver o seu problema é armazenar a chave de autenticação em um cookie e enviá-lo no cabeçalho HTTP, em seguida, fazê-lo, só não abusar dela. Lembre-se que as sessões são ruins, quando eles se tornam pesadas e grandes, se toda a sua sessão consiste de uma corda curta contendo uma chave, então qual é o problema?

Estou aberto a aceitar correções nos comentários, mas eu simplesmente não consigo ver o ponto (até agora) em fazer nossas vidas miseráveis ??simplesmente evitar manter um grande dicionário de hashes em nosso servidor.

Em primeiro lugar, um serviço web RESTful é SEM ESTADOS (ou em outras palavras, sessionless ). Portanto, um serviço RESTful não tem e não deve ter um conceito de sessão ou biscoitos envolvidos. A maneira de fazer autenticação ou autorização no serviço RESTful é usando o cabeçalho HTTP Authorization, tal como definido nas especificações HTTP RFC 2616. Cada pedido deve conter o cabeçalho HTTP Authorization, eo pedido deve ser enviado por uma conexão HTTPS (SSL). Esta é a maneira correta de fazer a autenticação e para verificar a autorização de pedidos de HTTP RESTful web services. Eu tenho implementado um serviço web RESTful para a aplicação Cisco PRIME Performance Manager da Cisco Systems. E como parte desse serviço web, eu implementei a autenticação / autorização bem.

Rubens Gomes.

Não é certamente sobre "chaves de sessão", como é geralmente usado para se referir a autenticação sessionless que é realizado dentro de todas as restrições de REST. Cada pedido é auto-descritivo, levando informações suficientes para autorizar o pedido em sua própria sem qualquer estado do aplicativo do lado do servidor.

A maneira mais fácil de abordar isso é começando com HTTP está embutido mecanismos de autenticação em RFC 2617 .

O artigo 'muito perspicaz' mencionado por @skrebel ( http://www.berenddeboer.net /rest/authentication.html ) discute um método complicado, mas realmente quebrado de autenticação.

Você pode tentar visitar a página (que é suposto ser visível apenas para o usuário autenticado) http://www.berenddeboer.net/rest/site/authenticated.html sem quaisquer credenciais de login.

(Desculpe eu não posso comentar sobre a resposta.)

Eu diria REST e autenticação simplesmente não se misturam. RESTO meios apátrida mas 'autenticado' é um estado. Você não pode ter os dois na mesma camada. Se você é um defensor RESTful e desaprovam estados, então você tem que ir com HTTPS (ou seja, deixar o problema de segurança para outra camada).

Eu acho que a autenticação repousante envolve a passagem de um token de autenticação como um parâmetro na solicitação. Exemplos são o uso de apikeys pela API. Eu não acredito que o uso de cookies ou http auth qualifica.

Atualização em 16-Feb-2019

A abordagem mencionado anteriormente abaixo é essencialmente "Resource Proprietário senha Credencial" Tipo de concessão de OAuth2.0 . Esta é uma maneira fácil de se levantar e correr. No entanto, com esta abordagem cada aplicação na organização vai acabar com seus próprios mecanismos de autenticação e autorização. A abordagem recomendada é concessão tipo "Código de Autorização". Além disso, na minha resposta anterior abaixo eu recomendado localStorage navegador para armazenar tokens de autorização. No entanto, tenho vindo a acreditar que cookie é a opção certa para esta finalidade. Eu ter detalhado as minhas razões, abordagem de implementação código de autorização concessão tipo, considerações de segurança etc. no esta resposta StackOverflow .

Eu acho que a seguinte abordagem pode ser usada para autenticação serviço REST:

  1. Criar uma API RESTful de login para aceitar nome de usuário e senha para autenticação. Use HTTP POST método para evitar o cache e SSL para a segurança durante o transporte Em autenticação bem-sucedida, a API retorna dois JWTs - um token de acesso (validade mais curto, digamos, 30 minutos) e um token de atualização (mais validade, digamos 24 horas)
  2. O cliente (a UI baseado na web) armazena os JWTs em armazenamento local e em cada chamada API subseqüente passa o token de acesso em "Autorização: Portador #access token" cabeçalho
  3. A API verifica a validade do token através da verificação da assinatura e data de validade. Se o token é válido, verifique se o usuário (Interpreta o "sub" reclamação em JWT como nome de usuário) tem acesso à API com uma pesquisa de cache. Se o usuário está autorizado a acessar a API, executar a lógica do negócio
  4. Se o IS de token expirado, a API retorna código de resposta HTTP 400
  5. O cliente, ao receber 400/401, invoca outra API REST com o token de atualização em "Autorização: Portador #refresh token" cabeçalho para obter um novo token de acesso.
  6. Ao receber a chamada com o token de atualização, verifique se a atualização token é válido, verificando a assinatura e a data de validade. Se o token de atualização é válida, atualizar o acesso ao cache direito do usuário de banco de dados e retorna o novo token de acesso e atualização de token. Se o token de atualização é inválido, código de resposta HTTP retorno 400
  7. Se um novo token de acesso e atualização de token são retornados, vá para o passo 2. Se código de resposta HTTP 400 é devolvido, o cliente assume que o token de atualização expirou e pede nome de usuário e senha do usuário
  8. Para logout, limpar o armazenamento local

Com esta abordagem estamos fazendo a operação cara de carregar o cache com acesso de usuário específico detalhes direito a cada 30 minutos. Então, se o acesso for revogada ou novo acesso é concedido, que leva 30 minutos para refletir ou um logout seguido por um login.

Essa é a maneira de fazer isso: usando OAuth 2.0 para login .

Você pode usar outros métodos de autenticação outro, em seguida, do Google, desde que ele suporta OAuth.

Para responder a esta pergunta de meu entendimento ...

Um sistema de autenticação que usa descanso para que você não precisa realmente controlar ou gerenciar os usuários em seu sistema. Isso é feito usando os métodos HTTP POST, GET, PUT, DELETE. Tomamos estes 4 métodos e pensar neles em termos de interação de banco de dados como criar, ler, UPDATE, DELETE (mas na web usamos GET e POST porque é isso que marcas de âncora apoiar atualmente). Assim, o tratamento GET e POST como nosso CRIAR / LEIA / update / delete (CRUD), então nós podemos projetar rotas em nossa aplicação web que será capaz de deduzir o que ação do CRUD estamos conseguindo.

Por exemplo, em um aplicativo Ruby on Rails podemos construir nosso aplicativo web de tal forma que, se um usuário que está logado visitas http://store.com/account/logout então o GET da página pode ser vista como o usuário que está tentando sair. Em nossos trilhos controlador que iria construir uma ação em que registra o usuário para fora e envia-los de volta para a página inicial.

A GET na página de login renderia um formulário. um POST na página de login seria visto como uma tentativa de login e tomar os dados POST e usá-lo para login.

Para mim, é uma prática de usar HTTP métodos mapeados para seu significado banco de dados e, em seguida, a construção de um sistema de autenticação com isso em mente que você não precisa passar em torno de qualquer id de sessão ou rastrear sessões.

Eu ainda estou aprendendo - se você encontrar qualquer coisa que eu disse a ser errado, por favor me correta, e se você aprender mais postá-lo aqui. Obrigado.

Usando um infrastruction de chave pública em que o registo de uma chave envolve garante vinculativas adequadas que a chave pública está vinculada ao indivíduo ao qual é atribuído de uma forma que garante não-repúdio

Consulte http://en.wikipedia.org/wiki/Public_key_infrastructure . Se você seguir os padrões de PKI apropriados, a pessoa ou o agente que usa indevidamente a chave roubados podem ser identificados e bloqueados. Se o agente é obrigado a usar um certificado, a ligação fica bastante apertado. Um ladrão inteligente e rápido movimento pode escapar, mas deixam mais migalhas.

Dicas válidos para proteger qualquer aplicação web

Se você quiser garantir a sua aplicação, , então você definitivamente deve começar usando HTTPS em vez de HTTP , isso garante um canal seguro criando entre você e os usuários que irão Prevenir sniffing os dados enviados de volta e para trás para os usuários e ajudará a manter os dados trocados confidenciais.

Você pode usar JWTs (JSON Web Tokens) para proteger APIs RESTful , este tem muitas vantagens quando comparada às sessões do lado do servidor, os benefícios são principalmente:

1- Mais escalável, como os servidores da API não terá de manter sessões para cada usuário (que pode ser um grande fardo quando você tem muitas sessões)

2- JWTs são auto-suficientes e têm as reivindicações que definem a função do usuário, por exemplo, e que ele pode acessar e emitido em data e prazo de validade (após o qual JWT não será válida)

3 mais fácil de manusear através balanceadores de carga e se você tiver vários servidores da API que você não terá que dados da sessão share nem servidor configure para encaminhar a sessão para mesmo servidor, sempre que uma solicitação com um JWT bater qualquer servidor que pode ser autenticado e autorizado

4 Menos pressão sobre o seu DB, assim como você não terá que armazenar constantemente e recuperar id de sessão e dados para cada solicitação

5- Os JWTs não pode ser adulterado se você usar uma chave forte para assinar a JWT, para que possa confiar nas declarações da JWT que é enviado com o pedido sem ter que verificar a sessão do usuário e se ele é autorizado ou não, você pode apenas verificar a JWT e, em seguida, está tudo pronto para saber quem & o que este usuário pode fazer.

Muitas bibliotecas oferecem maneiras fáceis de criar e JWTs Validar na maioria das linguagens de programação, por exemplo: em node.js um dos é o mais popular jsonwebtoken

Desde APIs REST geralmente tem como objetivo manter o apátrida servidor, por isso JWTs são mais compatíveis com esse conceito que cada pedido é enviado com a autorização token que é auto-contido (JWT) sem o servidor ter que manter o controle de sessão do usuário em comparação com sessões que fazem o stateful servidor para que ele lembra o usuário e seu papel, no entanto, as sessões também são amplamente utilizados e têm seus prós, que você pode procurar, se quiser.

Uma coisa importante a notar é que você tem que entregar com segurança a JWT para o cliente usando HTTPS e salvá-lo em um lugar seguro (por exemplo, no armazenamento local).

Você pode aprender mais sobre JWTs a partir deste link

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top