Personnaliser l'en-tête HTTP d'autorisation
J'ai besoin d'authentifier un client lorsqu'il envoie une demande à une API. Le client a un jeton API et je pensais utiliser l'en-tête standard Authorization pour envoyer le jeton au serveur.
Normalement, cet en-tête est utilisé pour l'authentification Basic et Digest. Mais je ne sais pas si je suis autorisé à personnaliser la valeur de cet en-tête et à utiliser un schéma d'authentification personnalisé, par exemple:
Authorization: Token 1af538baa9045a84c0e889f672baf83ff24
Recommanderiez-vous ceci ou non? Ou existe-t-il une meilleure approche pour envoyer le jeton?
Vous pouvez créer vos propres schémas d'authentification personnalisés qui utilisent le Authorization: en-tête - par exemple, voici comment OAuth .
En règle générale, si les serveurs ou les mandataires ne comprennent pas les valeurs des en-têtes standard, ils les laissent seuls et les ignorent. Il crée vos propres clés d'en-tête qui peuvent souvent produire des résultats inattendus - de nombreux mandataires vont effacer les en-têtes avec des noms qu'ils ne reconnaissent pas.
Cela dit, il est peut-être préférable d'utiliser des cookies pour transmettre le jeton, plutôt que le Authorization: en-tête, pour la simple raison que les cookies ont été explicitement conçus pour porter des valeurs personnalisées, alors que la spécification pour les méthodes d'authentification intégrées de HTTP ne dit pas vraiment de toute façon - si vous voulez voir exactement ce qu'il dit, have regardez ici .
L’autre aspect de cette question est que beaucoup de bibliothèques clientes HTTP prennent en charge les autorisations Digest et Basic, mais peuvent rendre la vie plus difficile en essayant de définir une valeur brute dans le champ d’en-tête, alors qu’elles fourniront toutes une prise en charge facile des cookies. permettre plus ou moins n'importe quelle valeur en eux.
Dans le cas de CROSS Origin demande, lisez ceci:
J'ai été confronté à cette situation et j'ai d'abord choisi d'utiliser l'en-tête Authorization, puis de le supprimer après avoir rencontré le problème suivant.
Authorization L'en-tête est considéré comme un en-tête personnalisé. Ainsi, si une requête interdomaine est effectuée avec le jeu d'en-tête Autorization, le navigateur envoie d'abord un demande de contrôle en amont. Une requête de contrôle en amont est une requête HTTP de la méthode OPTIONS. Cette requête supprime 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).
Ainsi, pour chaque requête envoyée par le client (navigateur), une requête HTTP supplémentaire (OPTIONS) était en cours d'envoi par le navigateur. Cela a détérioré les performances de mon API. Vous devriez vérifier si l'ajout de ceci dégrade vos performances. En guise de solution de contournement, j'envoie des jetons avec des paramètres http, ce qui, à mon avis, n'est pas la meilleure façon de le faire, mais je ne pouvais pas compromettre les performances.
C'est un peu démodé, mais il se peut que d'autres cherchent des réponses à la même question. Vous devriez réfléchir aux espaces de protection appropriés pour vos API. Par exemple, vous souhaiterez peut-être identifier et authentifier l'accès des applications clientes à vos API afin de limiter leur utilisation aux applications clientes enregistrées et connues. Dans ce cas, vous pouvez utiliser le schéma d'authentification Basic avec l'identifiant du client comme identifiant d'utilisateur et le secret client partagé comme mot de passe. Vous n'avez pas besoin de schémas d'authentification propriétaires mais identifiez clairement le ou les systèmes à utiliser par les clients pour chaque espace de protection. Je préfère un seul pour chaque espace de protection, mais les normes HTTP autorisent plusieurs schémas d'authentification pour chaque réponse d'en-tête WWW-Authenticate et plusieurs en-têtes WWW-Authenticate dans chaque réponse. ce sera déroutant pour les clients API quelles options utiliser. Soyez cohérent et clair, vos API seront utilisées.
Je recommanderais de ne pas utiliser l'authentification HTTP avec des noms de schéma personnalisés. Si vous sentez que vous avez quelque chose d'usage générique, vous pouvez définir un nouveau schéma, cependant. Voir http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2. pour plus de détails.
Veuillez essayer ci-dessous sur postier: -
Dans la section d'en-tête, un exemple fonctionne pour moi.
Autorisation: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSw 19 ans