O que é exatamente o token do portador do OAuth 2.0?

170

De acordo com a RFC6750 - A Estrutura de autorização do OAuth 2.0: uso do token de portador, o token do portador é:

Um token de segurança com a propriedade que qualquer parte em posse do token (um "portador") pode usar o token de qualquer maneira que qualquer outra parte em posse dele possa.

Para mim, essa definição é vaga e não consigo encontrar nenhuma especificação.

Suponha que eu esteja implementando um provedor de autorização, posso fornecer qualquer tipo de string para o token do portador?
Pode ser uma string aleatória?
Tem que ser uma codificação base64 de alguns atributos?
Deve ser hash?
E o provedor de serviços precisa consultar o provedor de autorização para validar esse token?

Obrigado por qualquer ponteiro.

oauth bearer-token

— Alex Beaupré
fonte

Suponha que eu esteja implementando um provedor de autorização, posso fornecer qualquer tipo de string para o token do portador? Pode ser uma sequência aleatória? Os tokens de acesso são emitidos pelos pontos de extremidade do OAuth 2.0 do Auth0: / authorize e / oauth / token. Você pode usar qualquer biblioteca compatível com OAuth 2.0 para obter tokens de acesso. Se você ainda não possui uma biblioteca OAuth 2.0 preferida, o Auth0 fornece bibliotecas para muitos idiomas e estruturas.

— Bharathkumar V

Respostas:

146

Token do portador
Um token de segurança com a propriedade de que qualquer parte em posse do token (um "portador") pode usá-lo da maneira que qualquer outra parte em posse dele possa. O uso de um token de portador não exige que o portador comprove a posse do material da chave criptográfica (prova de posse).

O token do portador é criado para você pelo servidor de autenticação. Quando um usuário autentica seu aplicativo (cliente), o servidor de autenticação vai e gera para você um token. Tokens de portador são o tipo predominante de token de acesso usado com o OAuth 2.0. Um token do portador basicamente diz "Conceda ao portador deste token".

O token do portador é normalmente algum tipo de valor opaco criado pelo servidor de autenticação. Não é aleatório; Ele é criado com base no usuário que fornece acesso e no cliente que seu aplicativo obtém acesso.

Para acessar uma API, por exemplo, você precisa usar um token de acesso. Os tokens de acesso têm vida curta (cerca de uma hora). Você usa o token do portador para obter um novo token de acesso. Para obter um token de acesso, você envia ao servidor de autenticação esse token de portador, juntamente com sua identificação de cliente. Dessa forma, o servidor sabe que o aplicativo que usa o token de portador é o mesmo aplicativo para o qual o token de portador foi criado. Exemplo: não posso simplesmente pegar um token de portador criado para o seu aplicativo e usá-lo com o meu aplicativo, ele não funcionará porque não foi gerado para mim.

O token do Google Refresh se parece com isso: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

copiado do comentário: acho que não há restrições nos tokens de portador que você fornece. A única coisa que consigo pensar é que é bom permitir mais de um. Por exemplo, um usuário pode autenticar o aplicativo até 30 vezes e os tokens do portador antigo ainda funcionarão. ah, e se não for usado por 6 meses, eu o removeria do seu sistema. É o seu servidor de autenticação que terá que gerá-los e validá-los para que você decida como é formatado.

Atualizar:

Um token de portador é definido no cabeçalho de autorização de cada solicitação HTTP de ação embutida. Por exemplo:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

A sequência "AbCdEf123456"no exemplo acima é o token de autorização do portador. Este é um token criptográfico produzido pelo servidor de autenticação. Todos os tokens de portador enviados com ações têm o campo de problema, com o campo de público especificando o domínio do remetente como um URL no formato https: //. Por exemplo, se o email for de noreply@example.com, o público será https://example.com .

Se estiver usando tokens de portadora, verifique se a solicitação é proveniente do servidor de autenticação e se destina ao domínio do remetente. Se o token não for verificado, o serviço deverá responder à solicitação com um código de resposta HTTP 401 (Não autorizado).

Os Tokens de portador fazem parte do padrão OAuth V2 e são amplamente adotados por muitas APIs.

— DaImTo
fonte

O token Xavier Egea Bearer é basicamente seu token de atualização e não o token de acesso.

— Akhil Nambiar

Portador de token não significa seu um token de atualização @AqeelSmith tools.ietf.org/html/rfc6750#section-6.1.1

— Suman Kundu

O primeiro parágrafo implica que um token de portador é um token de atualização e não um token de acesso. Este não é o caso. Na especificação do token do portador "Esta especificação descreve como fazer solicitações de recursos protegidos quando o token de acesso OAuth é um token do portador". RFC6750

— Daniel

Depois de ler a resposta, pensei também que o token do portador e os tokens de atualização são os mesmos. A resposta deve ser atualizada para esclarecer isso.

— KurioZ7 22/05/19

Esta resposta é muito enganadora. Os tokens do portador NÃO são token de atualização, como afirma a declaração inicial desta resposta. Por favor corrija.

— think01

Ao ler sua pergunta, tentei, sem sucesso, pesquisar na Internet como os tokens do Bearer são criptografados ou assinados. Eu acho que os tokens do portador não são hash (talvez parcialmente, mas não completamente) porque, nesse caso, não será possível descriptografá-lo e recuperar as propriedades dos usuários.

Mas sua pergunta parece estar tentando encontrar respostas na funcionalidade do token do Bearer:

Suponha que eu esteja implementando um provedor de autorização, posso fornecer qualquer tipo de string para o token do portador? Pode ser uma string aleatória? Tem que ser uma codificação base64 de alguns atributos? Deve ser hash?

Então, tentarei explicar como os tokens do portador e os tokens de atualização funcionam:

Quando o usuário solicita ao servidor um token enviando usuário e senha por SSL, o servidor retorna duas coisas: um token de acesso e um token de atualização .

Um token de acesso é um token de portador que você precisará adicionar em todos os cabeçalhos de solicitação para ser autenticado como um usuário concreto.

Authorization: Bearer <access_token>

Um token de acesso é uma sequência criptografada com todas as propriedades, reivindicações e funções do usuário que você deseja. (Você pode verificar se o tamanho de um token aumenta se adicionar mais funções ou reivindicações). Depois que o servidor de recursos receber um token de acesso, poderá descriptografá-lo e ler essas propriedades do usuário. Dessa forma, o usuário será validado e concedido juntamente com todo o aplicativo.

Os tokens de acesso têm uma validade curta (ou seja, 30 minutos). Se os tokens de acesso tivessem uma expiração longa, isso seria um problema, porque teoricamente não há possibilidade de revogá-lo. Imagine um usuário com uma função = "Admin" que muda para "Usuário". Se um usuário mantiver o token antigo com role = "Admin", ele poderá acessar até o vencimento do token com direitos de administrador. É por isso que os tokens de acesso têm uma validade curta.

Mas, uma questão vem à mente. Se um token de acesso tiver vencimento curto, precisamos enviar a cada curto período o usuário e a senha. Isso é seguro? Não é não. Nós devemos evitá-lo. É quando os tokens de atualização aparecem para resolver esse problema.

Os tokens de atualização são armazenados no banco de dados e terão uma validade longa (exemplo: 1 mês).

Um usuário pode obter um novo token do Access (quando ele expira, a cada 30 minutos, por exemplo) usando um token de atualização que o usuário recebeu na primeira solicitação de um token. Quando um token de acesso expira, o cliente deve enviar um token de atualização. Se esse token de atualização existir no DB, o servidor retornará ao cliente um novo token de acesso e outro token de atualização (e substituirá o antigo token de atualização pelo novo).

Caso um token de acesso do usuário tenha sido comprometido, o token de atualização desse usuário deverá ser excluído do DB. Dessa forma, o token será válido apenas até que o token de acesso expire, porque quando o hacker tentar obter um novo token de acesso enviando o token de atualização, essa ação será negada.

— Xavier Egea
fonte

Não entendo esta parte: "Quando o servidor de autorização receber um token de acesso, ele poderá descriptografá-lo e ler essas propriedades do usuário. Dessa forma, o usuário será validado e concedido ao longo de todo o aplicativo". O servidor de autorização não é aquele que concede o token de acesso, não o recebe? Estou tentando entender esse assunto e muitos exemplos fazem uma distinção clara entre o servidor de autorização e o servidor de recursos. O que eu entendi é que você obtém o token de acesso do servidor de autorização e o passa juntamente com todas as solicitações feitas ao servidor de recursos?

— kivikall

@kivikall Você está certo. Eu mudei na resposta. O servidor de recursos recebe o token (o token que o servidor de autorização criptografou no processo de criação do token) em cada solicitação e descriptografa-o.

— Xavier Egea

@kivikall Na verdade, descriptografar um token deve estar relacionado à autorização e, portanto, deve pertencer ao Servidor de Autorização. É por isso que a escreveu na resposta. Mas, na prática, isso significa que em todas as solicitações você deve validar com o Servidor de Autorização o token recebido (talvez executando outra solicitação). Portanto, para evitar perda de desempenho, é melhor fornecer algumas das funcionalidades para descriptografar o token no servidor de recursos. Verifique o próximo link: stackoverflow.com/questions/12296017/…

— Xavier Egea 14/17

Mas em todas as solicitações, o Servidor de Recursos deve verificar se o AccessToken fornecido é válido no Servidor de Autorização. Portanto, se uma função mudar, a alteração poderá ser refletida imediatamente pelo servidor de autenticação, certo? Além disso, por que excluiríamos o RefreshToken se o AccessToken foi comprometido? O RefreshToken não pode ser calculado com base no AccessToken; portanto, quando ele expira, o hacker é bloqueado novamente.

— tangerina

Como eu disse, o token de acesso contém informações do usuário, como a função. Se uma função de usuário mudar, essa alteração será refletida no próximo token quando o token atual expirar. Isso significa que, em um curto período de tempo (até a expiração do token de acesso), o usuário manterá a mesma função e o servidor de autenticação permitirá, porque o token ainda é válido. Em relação à segunda pergunta, a exclusão de um token de atualização faz com que o usuário insira suas credenciais novamente. É isso que queremos se um token de acesso for comprometido. Em outro caso, um hacker pode ser autorizada até o vencimento refreshtoken (por mês Ex.1)

— Xavier Egea

O token do portador é uma ou mais repetições de alfabeto, dígito, "-", "." , "_", "~", "+", "/" seguido por 0 ou mais "=".

RFC 6750 2.1. Campo do cabeçalho da solicitação de autorização (o formato é ABNF (BNF aumentado))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

Parece Base64, mas de acordo com o token no cabeçalho deve ser codificado em base64? , não é.

Indo um pouco mais fundo em "HTTP / 1.1, parte 7: Autenticação" **, no entanto, vejo que b64token é apenas uma definição de sintaxe ABNF, permitindo caracteres normalmente usados em base64, base64url, etc. Portanto, o b64token não defina qualquer codificação ou decodificação, mas apenas defina quais caracteres podem ser usados na parte do cabeçalho da Autorização que conterá o token de acesso.

Referências

— seg
fonte

Você não está explicando de todo o propósito os tokens do Portador.

— Jaime Hablutzel 28/04