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.

http rest header authorization NRaf
la source

Réponses:

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
la 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
la 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
la 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
la 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