En-tête d'autorisation HTTP personnalisé

124

Je me demandais s'il était acceptable de mettre des données personnalisées dans un en-tête d'autorisation HTTP. Nous concevons une API RESTful et nous pourrions avoir besoin d'un moyen de spécifier une méthode d'autorisation personnalisée. À titre d'exemple, appelons cela l' FIRE-TOKENauthentification.

Est-ce que quelque chose comme ça 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é API, la deuxième partie est un hachage de la chaîne de requête.

— NRaf
source

133

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

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

Où FIRE-TOKENest le schéma et les deux paires clé-valeur sont les paramètres d'authentification. Bien que je pense que les citations sont facultatives (de l'annexe B de p7-auth-19) ...

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

Je pense que cela correspond aux dernières normes, est déjà utilisé (voir ci-dessous) et fournit un format clé-valeur pour une extension simple (si vous avez besoin de paramètres supplémentaires).

Quelques exemples de cette syntaxe auth-param peuvent être vus 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

— StarTrekRedneck
source

4

L'API de stockage simple d'Amazon offre un autre exemple.

— évêque

18

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

La surcharge des en-têtes HTTP standard va probablement causer plus de confusion que cela ne vaut la peine et violera le principe de la moindre surprise . Cela peut également entraîner des problèmes d'interopérabilité pour vos programmeurs clients API qui souhaitent utiliser des kits d'outils prêts à l'emploi qui ne peuvent traiter que la forme standard des en-têtes HTTP typiques (tels que Authorization).

— Brian Kelly
source

3

Cela pourrait être plus difficile à faire qu'il n'y paraît. Le lien fourni par fumanchu (dans un commentaire à sa réponse) explique pourquoi l'introduction d'un en-tête personnalisé ajoute le fardeau supplémentaire de devoir maintenant définir manuellement le Cache-Control correctement.

— Jon-Eric

4

De plus, si vous faites une demande d'origine croisée via le navigateur, vous êtes maintenant en territoire de pré-vol simplement à cause de l'en-tête personnalisé où vous auriez autrement pu l'éviter. Pour certaines applications, ces demandes s'additionnent.

— Wil Moore III

31

Énorme non aux en-têtes d'authentification personnalisés. L'en- Authorizationtête standard avec votre propre schéma personnalisé devrait être plus que suffisant. De plus, vous évitez les demandes d'origine avant le vol comme l'indique @wilmoore. Les schémas personnalisés n'interfèrent pas avec les serveurs HTTP raisonnablement modernes que je connaisse, et si vous utilisez votre propre schéma, vous devrez l'analyser vous-même - aucune bibliothèque ne doit entrer en conflit (sinon la bibliothèque est mal écrite).

— Les Hazlewood

7

Une bonne raison de transmettre les informations d'identification dans l'en- Authorizationtête, plutôt que dans un en-tête personnalisé, est que les mandataires et les enregistreurs savent qu'il faut traiter les informations comme étant sensibles.

— Eron Wright

15

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

— fumanchu
source

1

Ce n'est pas correct. Voir page 5 du document pour un exemple de format: Autorisation: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— NRaf

11

C'est vrai. Mais comme le dit tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1 , "La notation" b64token "a été introduite pour la compatibilité avec les schémas d'authentification existants et ne peut être utilisée qu'une seule fois par défi / informations d'identification. Les nouveaux schémas devraient donc utiliser la syntaxe "auth-param" à la place, car sinon les extensions futures seront impossibles. " Voir aussi la discussion sur le cache concernant l'authentification dans les en-têtes personnalisés.

— fumanchu

9

Ancienne question que je connais, mais pour les curieux:

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

Vous pourriez faire de même, de sorte que l'exemple ci-dessus devienne:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— Mike Marcacci
source

4

Je déconseillerais cette réponse, car, par un commentaire sur une autre réponse ici , la notation utilisée ici est pour la compatibilité avec les schémas existants et n'est pas recommandée pour les nouvelles extensions.

— Whymarrh