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:
- 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.
- 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:
Armazene o ID do cliente / segredo no dispositivo e peça para o dispositivo orquestrar obtendo acesso aos recursos do usuário.
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.