A seção 4.2 do rascunho do protocolo OAuth 2.0 indica que um servidor de autorização pode retornar um access_token(que é usado para se autenticar com um recurso) e um refresh_token(que é usado apenas para criar um novo access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Por que ter os dois? Por que não apenas fazer o access_tokenúltimo, contanto que o refresh_tokene não tenha um refresh_token?
Respostas:
A idéia dos tokens de atualização é que, se um token de acesso for comprometido, por ter vida curta, o invasor terá uma janela limitada para abusá-lo.
Os tokens de atualização, se comprometidos, são inúteis porque o invasor exige o ID e o segredo do cliente, além do token de atualização, para obter um token de acesso.
Dito isso , porque todas as chamadas para o servidor de autorização e o servidor de recursos são feitas por SSL - incluindo o ID do cliente original e o segredo quando solicitam os tokens de acesso / atualização - não tenho certeza de como o token de acesso é mais " comprometível "do que o token de atualização de longa duração e a combinação clientid / segredo.
É claro que isso é diferente das implementações em que você não controla os servidores de autorização e de recursos.
Aqui está um bom tópico falando sobre o uso de tokens de atualização: Arquivos OAuth .
Uma citação do acima, falando sobre os objetivos de segurança do token de atualização:
Atualizar tokens ... reduz o risco de um acesso_token de longa duração (parâmetro de consulta em um arquivo de log em um servidor de recursos inseguro, aplicativo de servidor de recursos beta ou mal codificado, cliente JS SDK em um site não https que coloca o access_token em um cookie, etc)
O link para discussão, fornecido pela Catchdave, tem outro ponto válido (original, link morto) feito por Dick Hardt, que eu acredito que vale a pena mencionar aqui, além do que foi escrito acima:
Minha lembrança de tokens de atualização foi por segurança e revogação. <...>
revogação: se o token de acesso for independente, a autorização poderá ser revogada não emitindo novos tokens de acesso. Um recurso não precisa consultar o servidor de autorização para verificar se o token de acesso é válido. Isso simplifica a validação do token de acesso e facilita o dimensionamento e o suporte a vários servidores de autorização. Há uma janela de tempo em que um token de acesso é válido, mas a autorização é revogada.
De fato, na situação em que o Servidor de Recursos e o Servidor de Autorização são a mesma entidade e em que a conexão entre o usuário e um deles é (geralmente) igualmente segura, não faz muito sentido manter o token de atualização separado do token de acesso.
Embora, conforme mencionado na citação, outra função dos tokens de atualização seja garantir que o token de acesso possa ser revogado a qualquer momento pelo Usuário (por meio da interface da web em seus perfis, por exemplo), mantendo o sistema escalável ao mesmo tempo. .
Geralmente, os tokens podem ser identificadores aleatórios apontando para o registro específico no banco de dados do servidor ou podem conter todas as informações em si (certamente, essas informações precisam ser assinadas, com o MAC , por exemplo).
Como o sistema com tokens de acesso de longa duração deve funcionar
O servidor permite que o Cliente obtenha acesso aos dados do Usuário dentro de um conjunto predefinido de escopos, emitindo um token. Como queremos manter o token revogável, devemos armazenar no banco de dados o token, juntamente com o sinalizador "revogado" sendo definido ou desabilitado (caso contrário, como você faria isso com o token independente?) O banco de dados pode conter até len(users) x len(registered clients) x len(scopes combination)registros . Toda solicitação de API deve atingir o banco de dados. Embora seja bastante trivial fazer consultas a esse banco de dados executando O (1), o próprio ponto único de falha pode ter um impacto negativo na escalabilidade e no desempenho do sistema.
Como o sistema com token de atualização de longa duração e token de acesso de curta duração deve funcionar
Aqui, emitimos duas chaves: token de atualização aleatória com o registro correspondente no banco de dados e token de acesso independente assinado, contendo, entre outros, o campo de data e hora de expiração.
Como o token de acesso é independente, não precisamos acessar o banco de dados para verificar sua validade. Tudo o que precisamos fazer é decodificar o token e validar a assinatura e o carimbo de data e hora.
No entanto, ainda precisamos manter o banco de dados de tokens de atualização, mas o número de solicitações para esse banco de dados é geralmente definido pela vida útil do token de acesso (quanto maior a vida útil, menor a taxa de acesso).
Para revogar o acesso do Cliente de um Usuário em particular, devemos marcar o token de atualização correspondente como "revogado" (ou removê-lo completamente) e parar de emitir novos tokens de acesso. É óbvio, porém, que existe uma janela durante a qual o token de atualização foi revogado, mas seu token de acesso ainda pode ser válido.
Tradeoffs
Os tokens de atualização eliminam parcialmente o banco de dados SPoF (Ponto Único de Falha) do Token de Acesso, mas eles têm algumas desvantagens óbvias.
A janela". Um período entre os eventos "usuário revoga o acesso" e "o acesso é garantido para ser revogado".
A complicação da lógica do cliente.
sem token de atualização
com token de atualização
Espero que essa resposta faça sentido e ajude alguém a tomar uma decisão mais ponderada. Gostaria de observar também que alguns provedores conhecidos do OAuth2, incluindo o github e o foursquare, adotam o protocolo sem tokens de atualização e parecem felizes com isso.
Apesar de todas as ótimas respostas acima, eu, como estudante mestre em segurança e programador que trabalhava anteriormente no eBay, quando analisei a proteção e a fraude do comprador, posso dizer que separar o token de acesso e o token de atualização tem seu melhor equilíbrio entre assediar usuários com nome de usuário frequente / password e mantendo a autoridade em mãos para revogar o acesso a possíveis abusos no seu serviço.
Pense em um cenário como este. Você emite o usuário de um token de acesso de 3600 segundos e atualiza o token por mais um dia.
O usuário é um bom usuário, está em casa e liga / desliga o site comprando e pesquisando no iPhone. O endereço IP dele não muda e tem uma carga muito baixa no seu servidor. Como solicitações de 3-5 páginas a cada minuto. Quando seus 3600 segundos no token de acesso terminarem, ele precisará de um novo com o token de atualização. Nós, do lado do servidor, verificamos seu histórico de atividades e endereço IP, pensamos que ele é humano e se comporta. Concedemos a ele um novo token de acesso para continuar usando nosso serviço. O usuário não precisará digitar novamente o nome de usuário / senha até atingir um dia de vida do próprio token de atualização.
O usuário é um usuário descuidado . Ele mora em Nova York, EUA, desativou o programa de vírus e foi invadido por um hacker na Polônia . Quando o hacker obtém o token de acesso e o token de atualização, ele tenta se passar por um usuário e usar nosso serviço. Mas depois que o token de acesso de curta duração expira, quando o hacker tenta atualizar o token de acesso, nós, no servidor, notamos uma mudança drástica de IP no histórico de comportamento do usuário (ei, esse cara faz logon nos EUA e agora atualiza o acesso na Polônia depois de apenas 3600s ???). Encerramos o processo de atualização, invalidamos o próprio token de atualização e solicitamos a inserção do nome de usuário / senha novamente.
O usuário é um usuário mal - intencionado . Ele pretende abusar de nosso serviço chamando 1000 vezes nossa API a cada minuto usando um robô. Ele pode fazê-lo até 3600 segundos depois, quando tenta atualizar o token de acesso, notamos seu comportamento e pensamos que ele pode não ser humano. Rejeitamos e encerramos o processo de atualização e solicitamos que ele digite o nome de usuário / senha novamente. Isso pode potencialmente interromper o fluxo automático de seu robô. Pelo menos o deixa desconfortável.
Você pode ver que o token de atualização funcionou perfeitamente quando tentamos equilibrar nosso trabalho, experiência do usuário e risco potencial de um token roubado. Seu cão de guarda no lado do servidor pode verificar mais do que alterações de IP, frequência de chamadas da API para determinar se o usuário deve ser um bom usuário ou não.
Outra palavra é que você também pode tentar limitar o controle de danos do token / abuso de serviço roubado implementando em cada api chamada de cão de guarda IP básico ou quaisquer outras medidas. Mas isso é caro, pois você precisa ler e gravar registros sobre o usuário e diminuirá a resposta do servidor.
Nenhuma dessas respostas chega ao principal motivo de existirem tokens de atualização. Obviamente, você sempre pode obter um novo par de token de acesso / atualização-token enviando suas credenciais de cliente ao servidor de autenticação - é assim que você as obtém em primeiro lugar.
Portanto, o único objetivo do token de atualização é limitar o uso das credenciais do cliente enviadas por fio ao serviço de autenticação. Quanto menor o ttl do token de acesso, mais frequentemente as credenciais do cliente precisarão ser usadas para obter um novo token de acesso e, portanto, mais oportunidades os atacantes terão de comprometer as credenciais do cliente (embora isso possa ser super difícil de qualquer maneira, se criptografia assimétrica está sendo usada para enviá-los). Portanto, se você tiver um token de atualização de uso único, poderá reduzir arbitrariamente o ttl dos tokens de acesso, sem comprometer as credenciais do cliente.
Para esclarecer algumas confusões, você precisa entender as funções do segredo do cliente e a senha do usuário , que são muito diferentes.
O cliente é um aplicativo / site / programa / ..., apoiado por um servidor, que deseja autenticar um usuário usando um serviço de autenticação de terceiros. O segredo do cliente é uma sequência (aleatória) conhecida por esse cliente e pelo servidor de autenticação. Usando esse segredo, o cliente pode se identificar com o servidor de autenticação, recebendo autorização para solicitar tokens de acesso.
Para obter o token de acesso inicial e atualizar o token, é necessário:
Para obter um token de acesso atualizado, no entanto, o cliente usa as seguintes informações:
Isso mostra claramente a diferença: ao atualizar, o cliente recebe autorização para atualizar os tokens de acesso usando seu segredo do cliente e, assim, pode autenticar novamente o usuário usando o token de atualização em vez do ID do usuário + senha. Isso efetivamente impede que o usuário precise digitar novamente sua senha.
Isso também mostra que a perda de um token de atualização não é problema porque o ID e o segredo do cliente não são conhecidos. Também mostra que é vital manter o ID do cliente e o segredo secreto do cliente .
Esta resposta é de Justin Richer através da lista de e-mails do corpo padrão do OAuth 2. Isto é publicado com a sua permissão.
O tempo de vida de um token de atualização é de até o servidor de autorização (AS) - eles podem expirar, ser revogados etc. A diferença entre um token de atualização e um token de acesso é o público: o token de atualização só volta ao servidor de autorização, o token de acesso vai para o servidor de recursos (RS).
Além disso, obter um token de acesso não significa que o usuário efetuou login. De fato, o usuário pode nem estar mais lá, que é realmente o caso de uso pretendido do token de atualização. A atualização do token de acesso dará acesso a uma API em nome do usuário, mas não informará se o usuário está lá.
O OpenID Connect não fornece apenas informações de usuário de um token de acesso, mas também um token de identificação. Este é um dado separado que é direcionado ao próprio cliente, não ao AS ou ao RS. No OIDC, você só deve considerar alguém realmente "logado" pelo protocolo se conseguir obter um novo token de ID. Atualizar não é provável que seja suficiente.
Para mais informações, leia http://oauth.net/articles/authentication/
Os clientes podem ser comprometidos de várias maneiras. Por exemplo, um telefone celular pode ser clonado. Ter um token de acesso expirado significa que o cliente é forçado a se autenticar novamente no servidor de autorização. Durante a nova autenticação, o servidor de autorização pode verificar outras características (o IOW executa o gerenciamento de acesso adaptável).
Os tokens de atualização permitem a re-autenticação apenas de um cliente, onde, conforme a re-autorização, força um diálogo com o usuário que muitos indicaram que prefeririam não fazer.
Os tokens de atualização se encaixam essencialmente no mesmo local em que sites normais podem optar por autenticar periodicamente os usuários após uma hora ou mais (por exemplo, site bancário). No momento, ele não é muito usado, já que a maioria dos sites sociais não autentica novamente os usuários, por que eles autenticar novamente um cliente?
Por que não fazer apenas o access_token durar tanto quanto o refresh_token e não ter um refresh_token?
Além das ótimas respostas fornecidas por outras pessoas, há outro motivo pelo qual os tokens de atualização são usados e estão relacionados às reivindicações.
Cada token contém declarações que podem incluir qualquer coisa, desde o nome do usuário, suas funções ou o provedor que criou a declaração. À medida que um token é atualizado, essas declarações são atualizadas.
Se atualizarmos os tokens com mais frequência, obviamente colocaremos mais pressão em nossos serviços de identidade, no entanto, estamos recebendo reivindicações mais precisas e atualizadas.
Para simplificar ainda mais a resposta da BT: Use tokens de atualização quando você normalmente não deseja que o usuário digite novamente as credenciais, mas ainda deseja que o poder possa revogar as permissões (revogando o token de atualização)
Você não pode revogar um token de acesso, apenas um token de atualização.
Esta resposta foi elaborada com a ajuda de dois desenvolvedores seniores (John Brayton e David Jennes).
O principal motivo para usar um token de atualização é reduzir a superfície de ataque.
Vamos supor que não haja chave de atualização e vamos seguir este exemplo:
Um edifício tem 80 portas. Todas as portas são abertas com a mesma chave. A chave muda a cada 30 minutos. No final dos 30 minutos, tenho de dar a chave antiga ao fabricante de chaves e obter uma nova chave.
Se eu sou o hacker e pega sua chave, no final dos 30 minutos, eu a enviarei por correio ao fabricante de chaves e pegarei uma nova chave. Serei capaz de abrir todas as portas continuamente, independentemente da alteração da chave.
Pergunta: Durante os 30 minutos, quantas oportunidades de hackers tive contra a chave? Eu tive 80 oportunidades de hackers, cada vez que você usava a chave (pense nisso como fazendo uma solicitação de rede e passando o token de acesso para se identificar). Então essa é a superfície de ataque 80X.
Agora vamos seguir o mesmo exemplo, mas desta vez vamos assumir que há uma chave de atualização.
Um edifício tem 80 portas. Todas as portas são abertas com a mesma chave. A chave muda a cada 30 minutos. Para obter uma nova chave, não consigo passar o token de acesso antigo. Devo apenas passar a chave de atualização.
Se eu sou o hacker e obtemos sua chave, posso usá-la por 30 minutos, mas no final dos 30 minutos o envio para o keymaker não tem valor. Se sim, o fabricante de chaves diria apenas esse token de atualização incorreta. Para poder estender meu hack, eu teria que hackear o correio para o keymaker. O correio tem uma chave distinta (pense nisso como um token de atualização).
Pergunta: Durante os 30 minutos, quantas oportunidades de hackers tive contra a chave de atualização? 80? Não. Eu só tive 1 oportunidade de hacking. Durante o tempo, o correio se comunica com o chaveiro. Então essa é a superfície de ataque 1X. Eu tive 80 oportunidades de hackers contra a chave, mas elas não são boas após 30 minutos.
Um servidor verificaria um token de acesso com base nas credenciais e na assinatura (normalmente) de um JWT.
Um token de acesso vazando é ruim, mas depois que expira, não é mais útil para um invasor. Um token de atualização vazando é muito pior, mas presumivelmente é menos provável. (Acho que há espaço para questionar se a probabilidade de um token de atualização vazar é muito menor do que a de um token de acesso, mas essa é a ideia.)
O ponto é que o token de acesso é adicionado a cada solicitação que você faz, enquanto um token de atualização é usado apenas durante o fluxo de atualização. Portanto, menos chance de um MITM ver o token
A frequência ajuda um invasor. Possíveis falhas de segurança no SSL, falhas de segurança no cliente e falhas de segurança no servidor tornam possível o vazamento.
Além disso, se o servidor de autorização for separado do servidor de aplicativos que processa outras solicitações do cliente, esse servidor de aplicativos nunca verá tokens de atualização. Ele verá apenas tokens de acesso que não permanecerão por muito mais tempo.
A compartimentalização é boa para segurança.
Por último, mas não menos importante, veja esta resposta incrível
De que token de atualização NÃO se trata?
A capacidade de atualizar / revogar o nível de acesso por meio de tokens de atualização é um subproduto da escolha de usar tokens de atualização; caso contrário, um token de acesso independente pode ser revogado ou ter seu nível de acesso modificado quando expirar e os usuários receberem um novo token
Suponha que você faça o access_tokenúltimo por muito tempo e não tenha refresh_token, portanto, em um dia, o hacker consegue isso access_tokene ele pode acessar todos os recursos protegidos!
Mas, se você tiver refresh_token, o access_tokentempo de exibição é curto, portanto é difícil invadir o hacker access_tokenporque será inválido após um curto período de tempo.
Access_tokensó pode ser recuperado usando não apenas refresh_tokenmas também por client_ide client_secret, que o hacker não possui.
Enquanto o token de atualização é retido pelo servidor de Autorização. O token de acesso é independente, portanto, o servidor de recursos pode verificá-lo sem armazená-lo, o que economiza o esforço de recuperação em caso de validação. Outro ponto que falta na discussão é de rfc6749 # page-55
"Por exemplo, o servidor de autorização pode empregar a rotação do token de atualização na qual um novo token de atualização é emitido a cada resposta de atualização do token de acesso. O token de atualização anterior é invalidado, mas retido pelo servidor de autorização. Se um token de atualização for comprometido e subsequentemente usado por o invasor e o cliente legítimo, um deles apresentará um token de atualização inválido, que informará o servidor de autorização sobre a violação. "
Acho que o objetivo principal do uso do token de atualização é que, mesmo que o invasor consiga obter o token de atualização, o ID do cliente e a combinação secreta. Com as chamadas subseqüentes para obter novo token de acesso do invasor, é possível rastrear se todas as solicitações de atualização resultarem em novo token de acesso e token de atualização.
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Vamos considerar um sistema em que cada usuário está vinculado a uma ou mais funções e cada função está vinculada a um ou mais privilégios de acesso. Essas informações podem ser armazenadas em cache para melhor desempenho da API. Porém, pode haver alterações nas configurações de usuário e função (por exemplo, um novo acesso pode ser concedido ou o acesso atual pode ser revogado) e isso deve ser refletido no cache.
Podemos usar o acesso e atualizar os tokens para esse fim. Quando uma API é chamada com o token de acesso, o servidor de recursos verifica o cache para obter direitos de acesso. Se houver novas concessões de acesso, elas não serão refletidas imediatamente. Depois que o token de acesso expira (digamos em 30 minutos) e o cliente usa o token de atualização para gerar um novo token de acesso, o cache pode ser atualizado com as informações corretas de acesso do usuário atualizado do banco de dados.
Em outras palavras, podemos mover as operações caras de cada chamada de API usando tokens de acesso para o evento de geração de token de acesso usando o token de atualização.
Primeiro, o cliente se autentica no servidor de autorização, concedendo a concessão da autorização.
Em seguida, o cliente solicita ao servidor de recursos o recurso protegido, fornecendo o token de acesso.
O servidor de recursos valida o token de acesso e fornece o recurso protegido.
O cliente faz a solicitação de recurso protegido ao servidor de recursos, concedendo o token de acesso, onde o servidor de recursos o valida e atende à solicitação, se válido. Esta etapa continua repetindo até o token de acesso expirar.
Se o token de acesso expirar, o cliente se autentica no servidor de autorização e solicita um novo token de acesso, fornecendo o token de atualização. Se o token de acesso for inválido, o servidor de recursos retornará a resposta de erro do token inválido ao cliente.
O cliente se autentica no servidor de autorização concedendo o token de atualização.
O servidor de autorização valida o token de atualização autenticando o cliente e emite um novo token de acesso, se for válido.
access token + refresh token?