En-tête d'autorisation HTTP personnalisé

Question

Je me demandais s'il était acceptable de placer des données personnalisées dans un en-tête d'autorisation HTTP. Nous concevons une API RESTful et nous aurons peut-être besoin d'un moyen de spécifier une méthode d'autorisation personnalisée. Par exemple, appelons-la FIRE-TOKEN authentification.

Est-ce que quelque chose comme ce serait valide et autorisé selon les spécifications: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

La première partie de la deuxième chaîne (avant le ':') est la clé de l'API, la deuxième partie est un hachage de chaîne de requête.

Answer 1

Le format défini dans RFC2617 est - credentials = auth-scheme #auth-param. Donc, en accord avec fumanchu, je pense que le corrigé régime d'autorisation ressemblerait

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

Où FIRE-TOKEN est le schéma et les deux paires clé-valeur sont les auth paramètres. Mais je crois que les citations sont en option (à partir de l'Appendice B de p7-auth-19)...

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

Je crois que cela correspond aux normes les plus récentes, est déjà en cours d'utilisation (voir ci-dessous), et fournit un format clé-valeur pour la simple extension (si vous avez besoin de paramètres supplémentaires).

Quelques exemples de ce auth-param syntaxe peut être vu ici...

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

Answer 2

Placez-le dans un en-tête personnalisé séparé.

Surcharger les en-têtes HTTP standard va probablement causer plus de confusion que cela ne vaudra et va enfreindre le principe de la moindre surprise . Cela pourrait également entraîner des problèmes d'interopérabilité pour vos programmeurs clients d'API qui souhaitent utiliser des kits d'outils standards qui ne peuvent gérer que la forme standard des en-têtes HTTP classiques (tels que Authorization ).

Answer 3

Non, ce n'est pas une production valide selon la définition de "credentials" de la RFC 2617 . Vous donnez un schéma d'authentification valide, mais les valeurs auth-param doivent être de la forme token "=" ( token | quoted-string ) (voir section 1.2), et votre exemple n'utilise pas "=" de cette façon.

Answer 4

Vieille question, je sais, mais pour les curieux:

Vous ne voulez pas passer un colon avec l'en-tête de la valeur parce que ce serait le rendre invalide.

Croyez le ou non, ce problème a été résolu ~2 décennies avec de HTTP de BASE, qui passe de la valeur que encodées en base64 nom d'utilisateur:mot de passe. (Voir http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side)

On pourrait faire la même, de sorte que l'exemple ci-dessus devient:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==