Por que os tokens de acesso expiram?


209

Estou começando a trabalhar com a API do Google e o OAuth2. Quando o cliente autoriza meu aplicativo, recebo um "token de atualização" e um "token de acesso" de curta duração. Agora, toda vez que o token de acesso expirar, posso POSTAR meu token de atualização para o Google e eles me fornecerão um novo token de acesso.

Minha pergunta é qual é o objetivo do token de acesso expirando? Por que não pode haver apenas um token de acesso duradouro em vez do token de atualização?

Além disso, o token de atualização expira?

Consulte Usando o OAuth 2.0 para acessar as APIs do Google para obter mais informações sobre o fluxo de trabalho do Google OAuth2.

Respostas:


226

Isso é muito específico da implementação, mas a idéia geral é permitir que os provedores emitam tokens de acesso de curto prazo com tokens de atualização de longo prazo. Por quê?

  • Muitos provedores suportam tokens de portador, que são muito fracos em termos de segurança. Ao torná-los de vida curta e exigir atualização, eles limitam o tempo que um invasor pode abusar de um token roubado.
  • A implantação em larga escala não deseja executar uma pesquisa no banco de dados a cada chamada da API; em vez disso, eles emitem um token de acesso auto-codificado, que pode ser verificado por descriptografia. No entanto, isso também significa que não há como revogar esses tokens, portanto eles são emitidos por um curto período de tempo e devem ser atualizados.
  • O token de atualização requer autenticação do cliente, o que o torna mais forte. Ao contrário dos tokens de acesso acima, geralmente é implementado com uma pesquisa no banco de dados.

4
Duas perguntas: 1) No caso de aplicativos móveis, o requisito de autenticação de cliente o torna mais forte? Como o client_secret faz parte do código-fonte do aplicativo, não é de todo secreto. Supondo que o token de acesso também seja compartilhado apenas via TLS (e seu primeiro ponto de marcador não se aplica), existe alguma segurança extra? 2) Supondo que tudo isso ocorra em nosso cenário (apenas TLS, sem tokens irrevogáveis ​​e auto-codificados), é correto emitir tokens de acesso que não expiram?
Thilo

4
O que é um token de portador e o que ele tem a ver com tokens de atualização e acesso?
Allyourcode 11/11/12

7
@Thilo Acho que a ideia é que os tokens de acesso não precisem ser revogáveis. Como Eran aponta, isso possibilita que o serviço solicitado decida se deve atender a uma solicitação <em> sem precisar procurar o token de acesso em algum banco de dados </em>. AFAICT, esse é o benefício real de separar tokens de atualização e tokens de acesso.
allyourcode

5
Como um token de acesso (portador?) Dura pouco? Se eu fizer uma solicitação com um token de portador expirado, o token de atualização retornará um token de portador novo. Da mesma forma, se eu roubar o token de alguém de seus cookies e falsificar meu próprio cookie com esse token, eu o envio ao servidor, ele será atualizado e me enviará um novo. O que há para parar isso? Não diga endereço IP ou mesmo MAC, porque isso não é razoável.
Suamere 24/09/15

3
@ Suamere, isso já foi explicado. Os tokens do portador são validados por um processo criptográfico que não toca no banco de dados de autenticação, tornando-os muito mais eficientes para acesso frequente a recursos. Os tokens de atualização são validados em um processo que envolve a verificação do banco de dados para garantir que ele ainda seja válido. Agora pense em como o gmail funciona. Se alguém fizer login na sua conta a partir de uma localização geográfica inesperada, você poderá receber um alerta. Você pode ver todos os locais que podem ter tokens de atualização válidos no momento. Você pode fazer logout de todos os locais, invalidando todos os outros tokens de atualização.
Bon

33

Alguns cenários podem ajudar a ilustrar a finalidade de acessar e atualizar os tokens e as compensações de engenharia na criação de um sistema oauth2 (ou qualquer outro tipo de autenticação):

Cenário de aplicativo da Web

No cenário de aplicativo da web, você tem algumas opções:

  1. se você possui seu próprio gerenciamento de sessões, armazene o access_token e o refresh_token no seu ID de sessão no estado da sessão no seu serviço de estado da sessão. Quando uma página é solicitada pelo usuário que exige que você acesse o recurso, use o access_token e, se o access_token tiver expirado, use o refresh_token para obter a nova.

Vamos imaginar que alguém consiga invadir sua sessão. A única coisa possível é solicitar suas páginas.

  1. se você não possui gerenciamento de sessões, coloque o access_token em um cookie e use-o como uma sessão. Então, sempre que o usuário solicitar páginas do seu servidor da Web, envie o access_token. Seu servidor de aplicativos pode atualizar o access_token, se necessário.

Comparando 1 e 2:

Em 1, access_token e refresh_token apenas viajam pelo caminho entre o servidor de autorização (google no seu caso) e o servidor de aplicativos. Isso seria feito em um canal seguro. Um hacker pode seqüestrar a sessão, mas ele só poderá interagir com seu aplicativo da web. Em 2, o hacker pode retirar o access_token e formar suas próprias solicitações aos recursos aos quais o usuário concedeu acesso. Mesmo se o hacker se apossar do access_token, ele terá apenas uma pequena janela na qual poderá acessar os recursos.

De qualquer maneira, o refresh_token e o clientid / secret são conhecidos apenas pelo servidor, impossibilitando que o navegador da Web obtenha acesso a longo prazo.

Vamos imaginar que você esteja implementando o oauth2 e defina um tempo limite longo no token de acesso:

1) Não há muita diferença aqui entre um token de acesso curto e longo, pois está oculto no servidor de aplicativos. Em 2) alguém poderia obter o access_token no navegador e usá-lo para acessar diretamente os recursos do usuário por um longo tempo.

Cenário para celular

No celular, existem alguns cenários que eu conheço:

  1. Armazene o ID do cliente / segredo no dispositivo e peça para o dispositivo orquestrar obtendo acesso aos recursos do usuário.

  2. Use um servidor de aplicativos back-end para manter o clientid / segredo e fazer a orquestração. Use o access_token como um tipo de chave de sessão e passe-o entre o cliente e o servidor de aplicativos.

Comparando 1 e 2

1) Depois de ter clientid / secret no dispositivo, eles não são mais secretos. Qualquer um pode descompilar e começar a agir como se fosse você, com a permissão do usuário, é claro. O access_token e refresh_token também estão na memória e podem ser acessados ​​em um dispositivo comprometido, o que significa que alguém pode atuar como seu aplicativo sem que o usuário dê suas credenciais. Nesse cenário, o comprimento do access_token não faz diferença para a hackabilidade, pois refresh_token está no mesmo local que access_token. Em 2) o clientid / secret nem o token de atualização estão comprometidos. Aqui, a duração da expiração access_token determina por quanto tempo um hacker pode acessar os recursos dos usuários, caso eles se apossem dele.

Comprimentos de validade

Aqui, depende do que você está protegendo com seu sistema de autenticação e quanto tempo deve durar sua expiração de access_token. Se é algo particularmente valioso para o usuário, deve ser curto. Algo menos valioso, pode ser mais longo.

Algumas pessoas como o google não expiram o refresh_token. Alguns como o stackflow fazem. A decisão sobre a expiração é uma troca entre facilidade e segurança do usuário. O comprimento do token de atualização está relacionado ao tamanho do retorno do usuário, ou seja, defina a atualização com a frequência com que o usuário retornará ao seu aplicativo. Se o token de atualização não expirar, a única maneira de revogá-lo é com uma revogação explícita. Normalmente, um logon não seria revogado.

Espero que um post mais longo seja útil.


sobre o CENÁRIO MÓVEL, não importa se você armazena o ID do cliente no servidor. assim qualquer um aplicativo outra pessoa apenas pode enviar pedido para o servidor e pode acessar os usuários recursos throug servidor seu, então é o mesmo
Amir Bar

true, mas eles só têm acesso aos recursos que você fornece, em vez de acesso total ao token subjacente. Ou seja, eles podem se passar por seu aplicativo. Geralmente, os tokens podem ter permissões amplas, enquanto você só precisa de um subconjunto. Manter o token no back-end fornece mais restrições, caso você precise.
Ed Sykes

11

Além das outras respostas:

Uma vez obtidos, os Tokens de Acesso geralmente são enviados junto com todas as solicitações dos Clientes para os Servidores de Recursos protegidos. Isso induz um risco de roubo e reprodução de tokens de acesso (supondo que os tokens de acesso sejam do tipo "Portador" (conforme definido no RFC6750 inicial).

Exemplos desses riscos, na vida real:

  • Os servidores de recursos geralmente são servidores de aplicativos distribuídos e geralmente têm níveis mais baixos de segurança em comparação com os servidores de autorização (menor configuração SSL / TLS, menos proteção, etc.). Os servidores de autorização, por outro lado, são geralmente considerados uma infraestrutura de segurança crítica e estão sujeitos a um reforço mais severo.

  • Os tokens de acesso podem aparecer em rastreamentos HTTP, logs etc. coletados legitimamente para fins de diagnóstico nos servidores ou clientes de recursos. Esses traços podem ser trocados por locais públicos ou semi-públicos (rastreadores de bugs, service desk, etc.).

  • Os aplicativos de back-end RS podem ser terceirizados para terceiros mais ou menos confiáveis.

O token de atualização, por outro lado, normalmente é transmitido apenas duas vezes pelos fios, e sempre entre o cliente e o servidor de autorização: uma vez quando obtido pelo cliente e uma vez quando usado pelo cliente durante a atualização ("expirando" efetivamente a atualização anterior) símbolo). Esta é uma oportunidade drasticamente limitada para interceptação e reprodução.

Por último, os Refresh Tokens oferecem muito pouca proteção, se houver, contra clientes comprometidos.


Você tocou um pouco sobre isso, mas eu enfatizaria que a maior superfície de ataque para obter (ou divulgar inadvertidamente) tokens está nos logs de aplicativos ou nos serviços de recursos adicionados de forma nefasta (hoje não é um ataque MITM). Em quase todos os lugares em um back-end da API comum, há acesso ao token de acesso usado (se tiver acesso ao objeto HttpRequest etc). Somente DOIS caminhos de código no sistema têm acesso ao token de atualização - aquele que o gera em primeiro lugar e aquele que o troca por um novo token de acesso. Essa é uma diferença significativa na superfície de ataque.
precisa

9

É essencialmente uma medida de segurança. Se o seu aplicativo estiver comprometido, o invasor terá acesso apenas ao token de acesso de curta duração e não terá como gerar um novo.

Os tokens de atualização também expiram, mas devem durar muito mais tempo que o token de acesso.


45
Mas o invasor também não teria acesso ao token de atualização? e pode usar isso para criar um novo token de acesso?
levi

10
@levi, o hacker não pode usar o token de atualização para criar um novo token de acesso, porque o ID do cliente e o segredo do cliente são necessários junto com o token de atualização para gerar o novo token de acesso.
Pico

9
@ Spike True, mas o aplicativo não possui o ID e o segredo do cliente incorporados?
217 Andy

9
Portanto, ele fornece alguma proteção contra a detecção de pacotes, desde que a interceptação capte apenas solicitações de dados comuns (Chuck obtém apenas o token de acesso)? Isso parece um pouco fraco; o chapéu preto só precisa aguardar um pouco até que o usuário solicite um novo token de acesso e obtenha o ID do cliente, o segredo e o token de atualização.

3
Isso pode ser apenas um atraso aqui, mas se isso for enviado por SSL, isso não adiciona outra camada possível de segurança. Acho que estou assumindo que todos sabem o que é SSL.
Damon Drake
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.