security - oauth2 - refreshing access token




Por que o OAuth v2 tem acesso e atualização de tokens? (9)

A seção 4.2 do protocolo preliminar OAuth 2.0 indica que um servidor de autorização pode retornar um access_token (que é usado para autenticar-se com um recurso), bem como um refresh_token , que é usado apenas para criar um novo access_token :

https://tools.ietf.org/html/rfc6749#section-4.2

Por que ambos? Por que não apenas fazer o access_token durar tanto quanto o refresh_token e não ter um refresh_token ?


Por que não apenas fazer o access_token durar tanto quanto o refresh_token e não ter um refresh_token?

Além de ótimas respostas que outras pessoas forneceram, há outro motivo para usar tokens de atualização e suas reivindicações.

Cada token contém reivindicações que podem incluir qualquer coisa do nome do usuário, suas funções ou o provedor que criou a reivindicação. Quando um token é atualizado, essas declarações são atualizadas.

Se atualizarmos os tokens com mais frequência, obviamente estamos colocando mais pressão sobre nossos serviços de identidade, mas estamos recebendo afirmações mais precisas e atualizadas.


Primeiro, o cliente autentica com o servidor de autorização, concedendo a concessão de 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, em que o servidor de recursos o valida e atende à solicitação, se for válido. Essa etapa continua repetindo até que o token de acesso expire.

Se o token de acesso expirar, o cliente autenticará com o servidor de autorização e solicitará um novo token de acesso, fornecendo um token de atualização. Se o token de acesso for inválido, o servidor de recursos retornará a resposta de erro de token inválida ao cliente.

O cliente autentica com o servidor de autorização, concedendo o token de atualização.

Em seguida, o servidor de autorização valida o token de atualização, autenticando o cliente e emitindo um novo token de acesso, se for válido.


Apesar de todas as ótimas respostas acima, eu como um estudante de segurança e programador que anteriormente trabalhou no eBay quando dei uma olhada em proteção ao comprador e fraude, posso dizer que separar token de acesso e atualizar token tem seu melhor equilíbrio entre assediar usuário de nome de usuário frequente / entrada de senha e manter a autoridade em mãos para revogar o acesso a possíveis abusos do seu serviço.

Pense em um cenário como esse. Você emite o usuário de um token de acesso de 3600 segundos e atualiza o token por mais um dia.

  1. O usuário é um bom usuário, ele está em casa e entra e sai do site fazendo compras e pesquisando em seu iPhone. Seu endereço IP não muda e tem uma carga muito baixa no seu servidor. Como 3-5 pedidos de 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, achamos que ele é humano e se comporta. Concederemos a ele um novo token de acesso para continuar usando nosso serviço. O usuário não precisará inserir novamente o nome de usuário / senha até que ele tenha atingido um dia de vida útil do próprio token de atualização.

  2. O usuário é um usuário descuidado . Ele mora em Nova York, EUA, fez o desligamento do programa de vírus e foi hackeado por um hacker na Polônia . Quando o hacker recebe o token de acesso e atualiza o token, ele tenta personificar o usuário e usar nosso serviço. Mas depois que o token de acesso curto expirar, quando o hacker tentar atualizar o token de acesso, nós, no servidor, notamos uma mudança radical de IP no histórico de comportamento do usuário (ei, esse cara loga nos EUA e agora atualiza o acesso na Polônia depois de apenas 3600s ???). Terminamos o processo de atualização, invalidamos o próprio token de atualização e solicitamos que você insira novamente o nome de usuário / senha.

  3. O usuário é um usuário mal - intencionado . Ele tem a intenção de abusar do nosso serviço, ligando 1000 vezes nossa API a cada minuto usando um robô. Ele pode fazer isso até 3600 segundos depois, quando ele tenta atualizar o token de acesso, notamos seu comportamento e achamos que ele pode não ser humano. Rejeitamos e encerramos o processo de atualização e pedimos que ele insira o nome de usuário / senha novamente. Isso pode potencialmente quebrar o fluxo automático de seu robô. Pelo menos deixa-o desconfortável.

Você pode ver que o token de atualização agiu perfeitamente quando tentamos equilibrar nosso trabalho, a experiência do usuário e o risco potencial de um token roubado. O seu cão de guarda no lado do servidor pode verificar mais do que a mudança de IP, a frequência das chamadas de 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 roubado / abuso de serviço, implementando em cada API o nome do 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.


Enquanto o token de atualização é mantido pelo servidor de autorização. O token de acesso é autocontido para que o servidor de recursos possa 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 rotação de token de atualização na qual um novo token de atualização é emitido com 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 usado subseqüentemente por tanto o invasor quanto o cliente legítimo, um deles apresentará um token de atualização invalidado, que informará ao servidor de autorização a violação ".

Eu acho que o objetivo de usar o token de atualização é que, mesmo que o invasor consiga obter token de atualização, ID do cliente e combinação secreta. Com chamadas subsequentes para obter um novo token de acesso do invasor, elas podem ser rastreadas caso todas as solicitações de atualização resultem em novo token de acesso e token de atualização.


Nenhuma dessas respostas chega ao motivo principal da existência de tokens de atualização. Obviamente, você sempre pode obter um novo par de token de acesso / atualização enviando suas credenciais de cliente para o 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 pelo fio ao serviço de autenticação. Quanto mais curto for o ttl do token de acesso, mais frequentemente as credenciais do cliente terão que ser usadas para obter um novo token de acesso e, portanto, mais oportunidades terão os invasores comprometendo as credenciais do cliente (embora isso possa ser super difícil se criptografia assimétrica está sendo usada para enviá-los). Portanto, se você tiver um token de atualização de uso único, poderá tornar o ttl de tokens de acesso arbitrariamente pequeno sem comprometer as credenciais do cliente.


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 ser mencionado aqui, além do que foi escrito acima:

Minha lembrança de tokens de atualização era para segurança e revogação. <...>

revogação: se o token de acesso for autônomo, a autorização poderá ser revogada por não emitir 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 de token de acesso e facilita a escalabilidade e 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 é a mesma entidade e a conexão entre o usuário e qualquer 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 cotaçã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 escaloná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 devem ser assinadas, com 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 em um conjunto de escopos predefinido, emitindo um token. Como queremos manter o token revogável, devemos armazenar no banco de dados o token junto com o sinalizador "revogado" sendo definido ou não configurado (caso contrário, como você faria isso com token independente?) O banco de dados pode conter tanto quanto len(users) x len(registered clients) x len(scopes combination) registros len(users) x len(registered clients) x len(scopes combination) . Cada solicitação da API deve, então, atingir o banco de dados. Embora seja bastante trivial fazer consultas a esse banco de dados executando O (1), o ponto único de falha em si 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 autônomo assinado, contendo, entre outros, o campo timestamp de expiração.

Como o token de acesso é autônomo, 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 timestamp.

No entanto, ainda temos que 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 mais longa a vida útil, menor a taxa de acesso).

Para revogar o acesso do Cliente de um usuário específico, devemos marcar o token de atualização correspondente como "revogado" (ou removê-lo completamente) e parar de emitir novos tokens de acesso. É óbvio que há uma janela durante a qual o token de atualização foi revogado, mas seu token de acesso ainda pode ser válido.

Compensações

Os tokens de atualização eliminam parcialmente o SPoF (Ponto Único de Falha) do banco de dados do Access Token, embora tenham algumas desvantagens óbvias.

  1. A janela". Um período de tempo entre eventos "o usuário revoga o acesso" e "o acesso tem a garantia de ser revogado".

  2. A complicação da lógica do cliente.

    sem token de atualização

    • enviar solicitação da API com token de acesso
    • se o token de acesso for inválido, falhe e peça ao usuário para se autenticar novamente

    com token de atualização

    • enviar solicitação da API com token de acesso
    • Se o token de acesso for inválido, tente atualizá-lo usando o token de atualização
    • Se a solicitação de atualização for aprovada, atualize o token de acesso e envie novamente a solicitação inicial da API
    • Se a solicitação de atualização falhar, peça ao usuário para se autenticar novamente

Espero que esta resposta faça sentido e ajude alguém a tomar uma decisão mais ponderada. Gostaria de observar também que alguns provedores OAuth2 bem conhecidos, incluindo o github e o foursquare, adotam o protocolo sem tokens de atualização e parecem satisfeitos com isso.


Para esclarecer alguma confusão, 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 / ..., respaldado por um servidor, que deseja autenticar um usuário usando um serviço de autenticação de terceiros. O segredo do cliente é uma cadeia de caracteres (aleatória) que é 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 o token de atualização, o que é necessário é:

  • O ID do usuário
  • A senha do usuário
  • O ID do cliente
  • O segredo do cliente

Para obter um token de acesso atualizado, o cliente usa as seguintes informações:

  • O ID do cliente
  • O segredo do cliente
  • O token de atualização

Isso mostra claramente a diferença: ao atualizar, o cliente recebe autorização para atualizar tokens de acesso usando seu segredo de cliente e pode, assim, autenticar novamente o usuário usando o token de atualização, em vez do ID do usuário + senha. Isso evita efetivamente que o usuário tenha que digitar novamente sua senha.

Isso também mostra que perder 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 manter o ID do cliente e o segredo secreto do cliente é vital .


Para simplificar ainda mais a resposta da BT: Use tokens de atualização quando você normalmente não deseja que o usuário tenha que digitar credenciais novamente, mas ainda deseja que a energia 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.


Vamos considerar um sistema em que cada usuário esteja vinculado a uma ou mais funções e cada função esteja vinculada a um ou mais privilégios de acesso. Essas informações podem ser armazenadas em cache para melhor desempenho da API. Mas, então, pode haver mudanças nas configurações de usuário e função (por exemplo, o novo acesso pode ser concedido ou o acesso atual pode ser revogado) e isso deve ser refletido no cache.

Podemos usar tokens de acesso e atualização para esse fim. Quando uma API é chamada com token de acesso, o servidor de recursos verifica o cache em busca de direitos de acesso. Se houver novas concessões de acesso, isso não se reflete imediatamente. Quando o token de acesso expirar (digamos, em 30 minutos) e o cliente usar o token de atualização para gerar um novo token de acesso, o cache poderá ser atualizado com as informações corretas de acesso do usuário do banco de dados.

Em outras palavras, podemos mover as operações dispendiosas 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.





refresh-token