Personnaliser l'Autorisation d'en-tête HTTP

J'ai besoin d'authentifier un client quand il envoie une demande à un API. Le client dispose d'une API-jeton et je pensais à l'aide de la norme Authorization - tête pour envoyer le jeton pour le serveur.

Normalement cet en-tête est utilisé pour Basic et Digest d'authentification. Mais je ne sais pas si je suis autorisé à personnaliser la valeur de cet en-tête et d'utiliser un custom auth-régime d'e.g:

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

Recommanderiez-vous cette ou pas? Ou est-il une meilleure approche de l'envoi du jeton?

InformationsquelleAutor Thomas Watson | 2011-12-11

49

Vous pouvez créer vos propres auth schémas qui utilisent le Authorization: d'en - tête par exemple, c'est comment OAuth œuvres.

En règle générale, si les serveurs ou proxy ne comprends pas la valeurs de la norme en-têtes, ils vont les laisser seuls et de les ignorer. Il est de la création de votre propre en-tête clés qui peut souvent produire des résultats inattendus - beaucoup de procurations bande-têtes avec les noms qu'ils ne reconnaissent pas.

Cela dit, il est probablement une meilleure idée de l'utilisation de cookies pour transmettre le jeton, plutôt que de la Authorization: en-tête, pour la simple raison que les cookies ont été explicitement conçus pour transporter des valeurs personnalisées, tandis que la spécification HTTP intégré dans auth méthodes ne dit pas vraiment de toute façon - si vous voulez voir exactement ce qu'il ne dit, jetez un oeil ici.

L'autre point, c'est que beaucoup de client HTTP bibliothèques ont un support intégré pour la Digérer et l'authentification Basique, mais peut rendre la vie plus difficile lorsque vous tentez de définir une valeur brute dans le champ d'en-tête, alors qu'ils seront tous de fournir la facilité de soutien pour les cookies et permettra à plus ou moins n'importe quelle valeur à l'intérieur d'eux.
- Agréable à entendre, c'est comment OAuth œuvres. Je ne pas sûr que l'utilisation de cookies fait le client de la mise en œuvre plus simple. À moins que votre client est un navigateur, puis les règles pour travailler avec des cookies (chemin d'accès, la date de péremption, etc.) sont plus compliquées à mettre en œuvre dans un client que de juste se souvenir de définir un champ d'en-tête. La plupart des bibliothèques clientes en fait assez simple de définir correctement les en-têtes.
- bien que je ne peux pas être en désaccord avec vous sur le cookie de la portée des points, il ne devrait pas vraiment d'importance ici. Le champ d'application de l'authentification HTTP (à l'aide de la Authorization: en-tête) est par domaine. Cela signifie que si vous définissez le domaine du cookie "ce domaine" et le chemin d'accès à "/", il aura une portée identique à celle de HTTP auth. Cependant, il est vraiment pour vous - mais comme Julian Reschke points, vous ne devriez probablement pas définir un nouveau schéma d'authentification, sauf si vous feel that you have something of generic use - quelque chose qui pourrait être utilisé dans une autre application.
InformationsquelleAutor DaveRandom
8

Dans le cas de ORIGINE de la CROIX - demande de lire ceci:

J'ai fait face à cette situation et, au début, j'ai choisi d'utiliser le Authorization en-Tête et plus tard enlevé après face à la question suivante.

Authorization En-tête est considéré comme un en-tête personnalisé. Donc, si une demande de domaines est faite avec de la Autorization en-Tête jeu, le navigateur envoie d'abord un de contrôle en amont demande. Un contrôle en amont requête est une requête HTTP par la méthode des OPTIONS, cela demande des bandes de tous les paramètres de la requête. Votre serveur doit répondre avec Access-Control-Allow-Headers en-Tête ayant la valeur de votre en-tête personnalisé (Authorization en-tête).

Donc, pour chaque demande du client (navigateur) envoie une requête HTTP supplémentaire(OPTIONS) a été envoyé par le navigateur. Cela réduit les performances de mon API.
Vous devriez vérifier si l'ajout de cette dégrade les performances de votre. Comme solution je suis l'envoi des jetons dans les paramètres http, qui je sais n'est pas la meilleure façon de le faire, mais je ne pouvais pas faire de compromis avec la performance.
- Je suis aussi en considérant seulement l'envoi de mon sessionID http params. Pourquoi dites-vous que ce n'est pas la meilleure façon de faire? Il semble qu'elle a l'avantage de la robustesse contre les pare-feu de décapage en-têtes, et aussi contre l'origine de la croix de dégradation des performances. Quels sont ses inconvénients?
- L'inconvénient est que dans le cas de la requête GET. J'ai eu d'authentifier l'utilisateur à l'aide de mon Authorization token (données sensibles) pour mon application. Pour la même raison, nous ne devrions pas nous envoyer des données sensibles en OBTENIR, il ne faut pas utiliser jeton d'autorisation dans les params. Comme par w3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 "protocole HTTP ne DEVRAIENT PAS utiliser la fonction de formulaire pour la soumission de données sensibles".
- Vous pouvez stocker le jeton dans des cookies si vous n'aimez pas les en-têtes. (Ne pas confondre le jeton de session id). À noter qu'en PUT et DELETE, il va envoyer les OPTIONS de toute façon... sachez que la plupart du temps, vous utilisez un serveur côté client REST et un navigateur n'est pas considéré comme un très bon client REST.
InformationsquelleAutor Abhishek Kumar
5

C'est un peu daté, mais il peut y en avoir d'autres à la recherche de réponses à la même question. Vous devriez penser à ce que la protection des espaces sens pour votre Api. Par exemple, vous souhaitez peut-être d'identifier et d'authentifier le client demande l'accès à votre Api pour restreindre leur utilisation de connu, enregistré des applications de client. Dans ce cas, vous pouvez utiliser le Basic schéma d'authentification avec l'identificateur du client comme l'identifiant de l'utilisateur et le client partagent un secret que le mot de passe. Vous n'avez pas besoin de propriété schémas d'authentification juste d'identifier clairement le(s) à être utilisé par les clients pour chaque espace de protection. Je préfère un seul pour chaque espace de protection, mais la HTTP normes permettent à la fois de multiples schémas d'authentification sur chaque-tête WWW-Authenticate réponse et plusieurs WWW-Authenticate les en-têtes dans chaque réponse; ce sera source de confusion pour les clients API quelles sont les options à utiliser. Être cohérente et claire de votre Api seront utilisés.

InformationsquelleAutor Steve Dearborn
2

Je recommande de ne pas utiliser l'authentification HTTP avec le modèle personnalisé noms. Si vous sentez que vous avez quelque chose de générique à utiliser, vous peut définir un nouveau schéma, si. Voir http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 pour plus de détails.
- Le document de liaison est un projet de protocole HTTP/1.1. J'ai essayé de regarder dans la norme définitive et ne peut pas trouver quelque chose à propos de ce que j'ai à vous inscrire personnalisé régimes. Cela pourrait-il pas être juste, que, pendant le processus de rédaction, ils ont voulu trouver et de s'entendre sur les modes par défaut?
- Thomas, le document que j'ai référencé est la révision de la Rfc 2616/7 (qui n'ont pas de registre pour les schémas). C'est un travail en cours, mais se rapproche de la fin.
InformationsquelleAutor Julian Reschke
0

Veuillez essayer ci-dessous sur le facteur :-

Dans la section d'en-tête exemple, le travail pour moi..

Autorisation : JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1nij9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1zswiz2v0dgvycyi6e30sindhc1bvchvsyxrlzci6zmfsc2usimfjdgl2zvbhdghzijp7inbhdghzijp7inbhc3n3b3jkijoiaw5pdcisimvtywlsijoiaw5pdcisil9fdii6imluaxqilcjfawqioijpbml0in0sinn0yxrlcyi6eyjpz25vcmuiont9lcjkzwzhdwx0ijp7fswiaw5pdci6eyjfx3yionrydwusinbhc3n3b3jkijp0cnvllcjlbwfpbci6dhj1zswix2lkijp0cnvlfswibw9kawz5ijp7fswicmvxdwlyzsi6e319lcjzdgf0zu5hbwvzijpbinjlcxvpcmuilcjtb2rpznkilcjpbml0iiwizgvmyxvsdcisimlnbm9yzsjdfswizw1pdhrlcii6eyjkb21haw4iom51bgwsil9ldmvudhmiont9lcjfzxzlbnrzq291bnqiojasil9tyxhmaxn0zw5lcnmiojb9fswiaxnozxciomzhbhnllcjfzg9jijp7il9fdii6mcwicgfzc3dvcmqioiikmmekmtakdtaybwnnwhfjwvqvde41mlkzz2l3dvrod3zmww9ztlfxejlucthyadiwr09imlhhy3hazwuilcjlbwfpbci6im1hzgfulmrhbguxqgdtywlslmnvbsisil9pzci6iju5mjezyzyyywm2odzlmgmynzi2mjgzmij9lcjfchjlcyi6eyikx19vcmlnaw5hbf9zyxzlijpbbnvsbcxudwxslg51bgxdlcikx19vcmlnaw5hbf92ywxpzgf0zsi6w251bgxdlcikx19vcmlnaw5hbf9yzw1vdmuioltudwxsxx0sil9wb3n0cyi6eyikx19vcmlnaw5hbf9zyxzlijpbxswijf9fb3jpz2luywxfdmfsawrhdguioltdlcikx19vcmlnaw5hbf9yzw1vdmuioltdfswiawf0ijoxndk1mzuwnza5lcjlehaioje0otuznja3odl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rccxzddwiynu
- Êtes-vous vraiment envoyer le mot de passe/de hachage en JWT? C'est une simple base64.
- il est assez typique de la pratique du spa est d'encapsuler toute la session de l'utilisateur au sein de JWT (puisque c'est un document json), éliminant le besoin pour le stockage de session côté serveur.
- Je ne sais pas si c'est typique pour encapsuler quelque chose de plus qu'une sorte de jeton de session dans JWT (voir par exemple ce post).
- cet article plein de misleadings, il a obtenu certains points, mais beaucoup de ses points ne fait pas de sens et certains de puis il a juste contre sans aucune raison, je peux dire qu'il adore les cookies, et je pense qu'il a besoin d'obtenir certains de Boulangerie et de fixer son article, j'ai eu beaucoup de situations que j'ai utilisé des biscuits et des déchets de jours de travail, JWT avec localStorage m'a sauvé beaucoup de maux de tête et de temps, il est à seulement 2 heures de travail et bang, jamais le visiter à nouveau. Je me demande s'il l'a jamais développé une application mobile, essayé navigateurs avec très restreint des règles de sécurité et ainsi de suite.
- J'apprécierais si vous développez sur vos déclarations comme that article full of misleadings, a lot of his points does not make sense, etc. d'une certaine façon (sens, c'est probablement quelque chose au-delà d'un commentaire ici). Peut-être que vous pourriez écrire une réponse ou un blog? Il serait vraiment intéressant de comparer les arguments.
InformationsquelleAutor Madan Dale

Vous devez vous connecter pour publier un commentaire.