Cabeçalho de autorização HTTP personalizado

124

Eu queria saber se é aceitável colocar dados personalizados em um cabeçalho de autorização HTTP. Estamos projetando uma API RESTful e podemos precisar de uma maneira de especificar um método personalizado de autorização. Como exemplo, vamos chamá-loFIRE-TOKEN autenticação.

Algo assim seria válido e permitido de acordo com as especificações: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

A primeira parte da segunda sequência (antes de ':') é a chave da API, a segunda parte é um hash da sequência de consultas.

— NRaf
fonte

133

O formato definido no RFC2617 é credentials = auth-scheme #auth-param. Então, ao concordar com os fumanchu, acho que o esquema de autorização corrigido se pareceria

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

Onde FIRE-TOKENestá o esquema e os dois pares de valores-chave são os parâmetros de autenticação. Embora eu acredite que as citações são opcionais (do Apendix B de p7-auth-19) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

Acredito que isso se encaixa nos padrões mais recentes, já está em uso (veja abaixo) e fornece um formato de valor-chave para extensão simples (se você precisar de parâmetros adicionais).

Alguns exemplos dessa sintaxe auth-param podem ser vistos aqui ...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

— StarTrekRedneck
fonte

4

A API de armazenamento simples da Amazon oferece outro exemplo.

— Bishop

18

Coloque-o em um cabeçalho personalizado separado.

A sobrecarga dos cabeçalhos HTTP padrão provavelmente causará mais confusão do que vale a pena e violará o princípio da menor surpresa . Também pode levar a problemas de interoperabilidade para os programadores de clientes da API que desejam usar kits de ferramentas prontos para uso que só podem lidar com a forma padrão de cabeçalhos HTTP típicos (como Authorization).

— Brian Kelly
fonte

3

Pode ser mais difícil acertar do que parece. O link que os fumanchu fornecem (em um comentário à sua resposta) explica por que a introdução de um cabeçalho personalizado adiciona a carga adicional de agora ter que definir manualmente o Controle de cache corretamente.

— Jon-Eric

4

Além disso, se você estiver fazendo uma solicitação de origem através do navegador, agora está no território antes do voo apenas por causa do cabeçalho personalizado, onde, de outra forma, poderia evitá-lo. Para certos aplicativos, essas solicitações são adicionadas.

— Wil Moore III

31

Enorme não aos cabeçalhos de autenticação personalizados. O Authorizationcabeçalho padrão de especificação com seu próprio esquema personalizado deve ser mais que suficiente. Além disso, você evita solicitações de origem antes do voo, como @wilmoore indica. Esquemas personalizados não interferem com nenhum servidor HTTP razoavelmente moderno que eu conheça, além disso, se você usar seu próprio esquema, terá que analisá-lo por conta própria - nenhuma biblioteca deve entrar em conflito (caso contrário, a biblioteca será mal escrita).

— Les Hazlewood

7

Um bom motivo para transmitir credenciais no Authorizationcabeçalho, e não em um cabeçalho personalizado, é que os proxies e os registradores sabem tratar as informações como confidenciais.

— Eron Wright 22/03

15

Não, essa não é uma produção válida de acordo com a definição de "credenciais" na RFC 2617 . Você fornece um esquema de autenticação válido, mas os valores de auth-param devem estar no formato token "=" ( token | quoted-string )(consulte a seção 1.2) e seu exemplo não usa "=" dessa maneira.

— fumanchu
fonte

1

Isso não está correto. Consulte a página 5 do documento para obter um exemplo de formato: Autorização: QWxhZGRpbjpvcGVuIHNlc2FtZQ == Básico

— NRaf

11

Isso é verdade. Porém, como tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1 diz: "A notação" b64token "foi introduzida para compatibilidade com os esquemas de autenticação existentes e só pode ser usada uma vez por Desafios / credenciais. Portanto, novos esquemas devem usar a sintaxe "auth-param", pois, caso contrário, extensões futuras serão impossíveis ". Consulte também a discussão em cache sobre a autenticação em cabeçalhos personalizados.

— Fumanchu 18/10/11

9

Velha pergunta eu sei, mas para os curiosos:

Acredite ou não, esse problema foi resolvido ~ duas décadas atrás com o HTTP BASIC, que passa o valor como nome de usuário codificado em base64: senha. (Consulte http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

Você pode fazer o mesmo, para que o exemplo acima se torne:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— Mike Marcacci
fonte

4

Eu desaconselho essa resposta, pois, por um comentário em outra resposta aqui , a notação usada aqui é para compatibilidade com os esquemas existentes e não é recomendada para novas extensões.

— Whymarrh