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

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.

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 [email protected], 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.

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.

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

• RFC 5234 3.6. Repetição variável: * Regra
• RFC 2616 2.1 BNF aumentado