Criando uma API com tokens de acesso, como lidar com solicitações GET?

Estou criando uma API que utilizará tokens de acesso para que eu possa rastrear o uso entre vários departamentos e para controle de acesso. Meu plano é utilizar os verbos HTTP adequadamente - GETrecuperará informações, POSTadicionará, DELETEexcluirá etc.

Minha pergunta é: como devo lidar com tokens de acesso nas chamadas GET?

Opção um:

É fornecer o token de acesso como parte da string de consulta: /api/users/?token=ACCESSTOKEN. O problema que tenho com isso é que o ACCESSTOKEN aparece nos logs do servidor. Esse método também será diferente das solicitações POST ou DELETE que têm o token passado pelo corpo.

Opção dois:

Forneça um corpo para a solicitação (como você faz em uma POSTsolicitação) e um dos parâmetros é o token. Meu problema aqui é que outros desenvolvedores da minha empresa estão me dizendo que essa não é uma "verdadeira solicitação GET" porque estou transmitindo dados. O URL que eles chamam simplesmente se parece com isso /api/users/e eles fornecem token=ACCESSTOKENdentro do corpo.

Opção três:

Solte usando GETe force tudo a ser POST. Não gosto dessa ideia porque, para muitas dessas chamadas de API, não estou criando novos recursos. Estou simplesmente retornando dados que ficam atrás de uma API que requer autorização.

Existe uma opção que estou faltando ou que devo refinar? Gosto da opção 2, mas sou sensível às preocupações de outros desenvolvedores de departamento.

Opção 4: Cabeçalhos de Autorização e RFC 6750 (Tokens de Portador)

A solução que você está procurando já foi especificada como parte do padrão OAuth2, mas é autônoma e será útil no seu cenário.

https://tools.ietf.org/html/rfc6750

Todas as solicitações do cliente passam um token de portador (seu token de acesso) e parece com qualquer outro cabeçalho de solicitação para o servidor. A solicitação em si é assim:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Como é um padrão público amplamente implementado, você não precisa se preocupar em definir comportamento - basta apontar os desenvolvedores do lado do cliente na RFC. Você também pode considerar implementar o restante do padrão OAuth2 como um servidor de recursos e um servidor de autorização , mas isso é muito mais trabalhoso.

Por que você não usa cabeçalhos de solicitação? Isso separa os dados de autenticação / autorização dos dados significativos reais da solicitação e pode ser usado para qualquer tipo de solicitação (o uso de um corpo de solicitação em um get geralmente é algo que você não deve fazer.)

Ter autorização nos cabeçalhos permite autenticar o usuário antes de analisar o corpo da solicitação, o que é vantajoso quando você não deseja que seu sistema perca tempo analisando dados de um usuário não autorizado.